0.1*0.1=0.01
But it comput 0.01000000000000002
Yes, I’ve seen some of these rounding errors. You might have to use the “round” block to force the correct value.
I’m actually having a problem where 0 + 75 x 0 = 10.98124675. Kind of hard to wrap my mind around that one! The 75 is a numeric value but… I’m pretty sure zero times anything is zero.
2 Likes
Wow- that’s way bigger than rounding error!
2 Likes
Yeah, and I’ve only noticed it on the Canvas. I’m setting a sprite’s y position to 0 and another sprite’s y position to 75. The “app variable bar spacing” is set to 75 at initialization.
When I check the value of bar 1’s y position using a canvas label, it gives me that crazy 10.9… number. And it’s clearly not positioned 75 pixels above bar 2. It’s actually about 64 pixels away. So strange. None of it makes much sense to me!
Edit: the problem seems to be caused when there is a variable, not necessarily by the math itself. I tried setting a sprite’s y value to 100 and it worked. I then tried initializing a variable to 100 and setting the same sprite’s y value to the variable and… it was off by about 50 pixels.
3 Likes
@domhnallohanlon I think it is necessary to notify thunkable 
1 Like
Reported this bug here:
2 Likes
I think you found the secret robot internet* @tony.ycy.program 
*source: Saturday Morning Breakfast Cereal - 2013-06-05
Joking aside, I’ll flag this with the team and see what we can do.
Thanks!
5 Likes
I can not understand!
It was a joke. It’s a robot secret because typically humans don’t see these weird math outcomes. However, the computer always knows what it thinks.
Check out this blog post for more information about why you’re getting this weird outcome. One piece of base knowledge you must have is the knowledge that thunk a bowl is backed with JavaScript. Underneath the hood it runs react native. Behind react native is react JS. Which is a fancy JS framework. So end of day, thunkable apps are powered by JavaScript (pretty much)
2 Likes
Still don’t really get this:
In JavaScript, all numbers are floating-point numbers, so when we write expressions like
0.1 + 0.2, it’ll return some numbers that we don’t expect like0.30000000000000004.0.1 and 0.2 are approximated to their true values. The approximated value of 0.2 is larger than its rational equivalent, but the closest approximating of 0.3 is smaller than the rational number.
Then we end up with the sum of 0.1 and 0.2 is slightly larger than the rational number 0.3 because 0.2’s approximation is slightly larger when approximated.
I mean why would a computer need to approximate 0.2 when it’s already an exact value (1/5)? I could understand approximating 1/3 or another repeating decimal.
2 Likes
The issue is that the computer represents everything in binary, to a limited amount of precision. So you can get weirdness like that because your values get converted into floating point numbers, then back to decimal after the addition, and they get just slightly off in the process.
You can hide that this is happening by specifying some modest number of decimal places. (There’s a Thunkable math block for that.)
As a chemist, I’m mostly not offended, since I’m thinking about significant digits and I know that 0.3000000000004 is really 0.3000 if my values (measured numbers) are really 0.1000 and 0.2000.
I don’t think this is related to your issue with sprites and pixels. This is just a floating point error.
2 Likes
Right, these are two different issues and I agree that the margin of error in terms of decimal values is pretty much a non-issue except… if I needed to check that a sprite’s location equals 0 or 50 or 127 and it was off by 0.00000001 it might not trigger the condition I expect it to.
But my concern is more about the seemingly random position values of my sprites which are off by 10-30 pixels rather than a fraction of a pixel.
2 Likes
Right. Your sprites bug is a real, Thunkable-specific bug that I hope the devs will fix. The floating point thing is not specific to Thunkable, and given that Thunkable is mostly a prototyping toy, I don’t expect it to be high on the devs’ list. You definitely can (and perhaps should) mitigate the concern with a round function if you’re comparing a calculated value to another value (and not using > or <).
3 Likes
If you limit your display to 6-8 decimal places, you won’t see it either.
2 Likes
Same problem in my calculator app:
2 Likes
Look this
I found that javascript will calculate 0.1 0.2=0.300000000004 but C will not. It seems that they have their own solution. It is really hard to write programs if it is not allowed to!
As long as every computing app made with thunkale is applied to floating point numbers, accidents are likely to happen!
0.1*0.1!=0.01 but 0.01*0.1=0.001
1 Like
Oh my gosh, all my apps use math tool and they were published in appstore.
Please don’t spam the forum with the same query. You already have a topic about this so stick to it.
3 Likes