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.
Wow- that’s way bigger than rounding error!
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.
@domhnallohanlon I think it is necessary to notify thunkable
Reported this bug here:
I think you found the secret robot internet* @tony.ycy.program
Joking aside, I’ll flag this with the team and see what we can do.
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.
Still don’t really get this:
0.1 + 0.2, it’ll return some numbers that we don’t expect like
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.
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.
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.
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 <).
If you limit your display to 6-8 decimal places, you won’t see it either.
Same problem in my calculator app:
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!