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.
P.S.
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.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?
Hi ABG,
"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!
Mark
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.
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.
Where do you find sawdust?
On the floor.
and in the air all around, before it settles 
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.
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:
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.
Thank you!
Thanks, good to learn about this option
I'll leave the high-level conversation to you and ABG!
Have a good day
(added to FAQ)
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.
