Bug Report: Math operations introduce error


@Ana @awesomeonion This bug needs your attention.

Math operations (a Set block with math or an Increase By block) are introducing error into the variable values and causing rules not to work.

This is a particularly insidious bug since the Player limits the precision of displayed values (when using Set text), which means that when someone tries to troubleshoot the problem, the value appears to be to the expected value but actually is not.

One example (forum topic) of confused Hopscotchers
{Edit: Nevermind. The rediculous disallowance of any phrase starting with f and ending in k prevents me from giving the topic URL here. See link at bottom of this post.}

This project demonstrates the bug:

A value is initially set to -2.1 and everything is fine:

Then increase the value by 1 (tap anywhere on the right half of the screen) and the value is no longer precisely accurate (but the Player still handles it correctly in a conditional rule):

Increase the value by 1 again and now the Player no longer evaluates the conditional rule correctly:


  • Initially only -0.1 & 0.9 evaluate incorrectly.
  • Once you reach -4.1 or 4.9, then the values from -3.1 to 3.9 evaluate incorrectly
  • Once you reach -16.1 or 16.9, then the values from -15.1 to 15.9 evaluate incorrectly

This implies there is also an increasing accumulation of error

Okay... what? Block not triggering for no reason

Hi, I’ll take a look, though I suspect you are running into a floating point error. Maybe we can use double values for more accuracy, but at sufficiently large numbers this will always be a problem.


It’s not large numbers or numbers that need a lot of precision that are the problem.

Just setting a variable to 1.1 and subtracting 1 does not cause a ‘When variable = 0.1’ rule to execute, because the variable seems to actually equal 0.10000000000000001 (or something like that)

This doesn’t cause the shape to change colors


This is weird too… this is a picture of some of some of my code… (note the ‘set self number’)

Then I press play and this happens: Where did the one come from?


Weird. I hope that THT can solve this, now that they´ve addressed the bug and that they have steps to replicate it.


*ridiculous * :grinning:
It is really easy to get past the filter though. Just type <h > in the middle like this: feed<h >back and then it looks like this: Feedback!

Or… if you want to, @Fredrick


That won’t work in links. To post links you have to remove all k’s.


You’re right, it’s not limited to big numbers. Though it is an issue with javascript (and programming languages in general).


Wow. So I was conceptually aware of the limitations of floating point numbers, but I just assumed that was “handled” by lower level software or hardware so that higher level software would know that, for example, 0.1 + 0.2 = 0.3

My head just exploded a little to learn many, or perhaps most, programming languages think 0.1 + 0.2 != 0.3 (does not equal)
(Ref: https://0.30000000000000004.com)

And I’m honestly struggling to comprehend how that’s ok.


Hi @awesomeonion, I’ve been trying to educate myself more on this topic & specifics as related to js.

From what I’ve come to understand, js only has one number type format. So numbers in js are already binary double precision floats (IEEE 754-2008 ‘binary64’)

Perhaps I’m wrong but it seems like advisable options are limited

  1. Status quo
  2. Use a library like bignumber.js

As an aside, are you doing something like this to parse inputs from blocks that expect numbers?

function acceptNumber(n) {
if (Number.isNaN(Number.parseFloat(n))) {
return 0;
return parseFloat(n);

Just reverse engineering, the behavior seems to follow the ECMA-262 definitions of parseFloat. E.g., without the quotes

  • “123 {text notes}” // expected value 123
  • 123e-3 // expected value 0.123

Since exponential notation is valid as a StrDecimalLiteral it would be helpful if the editor GUI allowed entry of the “e” instead of having to cut and paste. Although personally, I think I’d prefer if the Set {var} block brought up the iOS keyboard instead up using a custom GUI number pad. This way users could not only type the exponentIndicator, but text/comments that would be ignored, and most importantly directly edit any digit in the value (as opposed to the editor that forces you to delete and retype all digits from the right). But clearly that would be a significant departure from the existing editor design.


Hi there, you’ll be happy to know, the latest webplayer (f59fc18 on your about page) has fixed this issue. The bug is a weird implementation detail of binary math and shouldn’t be something you have to deal with as a Hopscotch programmer!


That’s great. I was recently considering how to try to explain the apparent “bug” (i.e. floating point arithmetic error) to my kids or an audience of hopscotchers. Addressing it ‘under the hood’ is a much better idea. :slightly_smiling_face:

May I ask what approach you’re using to addrèss the error?

Performance issues and other bugs