Counter shows gibberish when it should show number "0"

My issue: I have a number in label which I can increase or decrease by 1 or 0.1 by tapping on buttons.

Often, after playing around a little and getting back to zero, instead of showing "0", it shows some gibberish, usually with a capital E in there, like: "-2.7756E-17".

This only happens if I have also used the incremental changes.

You can replicate the error quickly on my tiny testing app: Tap "+1" to get the value "1", then tap "-0.1" ten times in a row to get back to what should be "0" but instead is some messed up number


zero_issue.aia (2.4 KB)


The gibberish you see is actually a number in scientific notation. What you see represents a very small value. You might use a Math format block ahead of the Number Block to set the number of decimal places. :slightly_smiling_face: That will take the display out of scientific notation mode.

Why does it happen? A guess is you are touching the buttons very rapidly and that is confusing the Math algorithm by not giving the app time to respond.

Did you notice you have an empty puzzle piece in your Reset.Click event handler? Perhaps that relates to your issue by setting Number to a value that is not a number.

1 Like

I filled it, it doesn't changed anything, its weird!

It is a side effect of inexact arithmetic.

0.1 is an infinite length quantity in binary, like 1/3 is an infinite length decimal number.

You got math sawdust.

AI2 might still support rational number data type arithmetic, if you substitute 1/10 for 0.1 everywhere. But some math operations result in floating point results , so avoid those.

1 Like

1.1102E-16 = 1.1102 * 10^-16

An exercise for further study:

How many binary digits are needed to store 1.1102 * 10^-16 ?

How does that compare to the floating point spec mentioned in the first (ewpatton) article in the Math FAQ?


"0.1 is an infinite length quantity in binary, like 1/3 is an infinite length decimal number."

Ok, but then, why does this only seem to happen at zero?

As for a solution, I will try to replace 0.1 with 1/10.

Thanks for your explanation, much appreciated!


Near zero, a floating point number starts to expose incremental losses of accuracy.

There's also the salami effect, which banking software guards against.

(Not to encourage a life in cyber-crime)

I hope you got to read the comprehensive post by ewpatton at

You may need to study up on floating point formats first.

1 Like

using fractions here does not change anything

I may just need to work around it with if-then blocks to correct the value back to "0.0000" at zero.

This will do as a work around

This has the advantage (in my case) of also formatting 0.0 to 0

Where do you find sawdust?

On the floor.

1 Like

and in the air all around, before it settles :wink:

Technically, the rounding errors occur at pretty much every number once you get small enough fractional differences that cannot be expressed neatly in the 53 bits of mantissa of a double floating point number. For example, 0.1 + 0.1 + 0.1 will give you 0.30000000000000004. Typically when App Inventor renders a number it does so only to 5 decimal places by default so you don't see the error. However, in the case of numbers near zero, scientific notation is a more compact and accurate representation, so you end up being able to see the accumulated error in a more up-front way since that's all that remains. The use of the floor or round functions may be useful in this case.

1 Like

Do you see any better solution to mine (using that "correct_zero" procedure)? Round doesn't work, right, because I do use decimals

The format as decimal block is likely a good candidate:

yielded "0.0" and using "Do It" on the math block feeding into it yielded a scientific notation number on the order of 10^-17.

Work in tenths of points, so you keep only whole numbers until display time?

For 0.1 keep 1, for 0.2 keep 2,...

Save the divide by 10 until the end.

Does that rational number data type still exist in the AI2 math stack, or am I on a wild goose chase?

I think these days all of the exact numbers are converted back to inexact numbers when they get passed up to the user. It might take me a little while to verify that.

Ok, so it looks like there are only two places where we are converting exact numbers to inexact numbers. The first is in conversion from numbers to strings, and the second is in the division operator. Therefore, you can still get some access to the rational numbers but unfortunately you can't really visualize them because the number to string coercion will convert them from their rational representation to the decimal representation. But, you can still do something like this:

blocks (85)

And the latter will return 0 rather than the floating point error of adding and then subtracting something near 0.1 but not actually 0.1.

1 Like

Thank you!