Floating point is so annoying


i am having an issue with converting my wow project from forever ago to js, and ive gotten it very close but since the nature of the project is chaotic, even the slightest deviation in calculations causes it to behave differently. and what i would like is an exact replica. ive done this before in a desmos project, and it hits right on the money, so i wasnt expecting to have much trouble. ive debugged comparing values between my js implementation and the snap version, and came across this quirk.

untitled script pic (1)

untitled script pic (2)

now i dont see why these arent identical. i couldnt locate in source code what functions are responsible for this, but im curious as to whats happening here.

also, unrelated, bh is a real one, for some reason i got super embarrassed for writing that comment because i felt like i kind of lost my cool and i guess was worrying about getting a 'what the hell are you even talking about' reply, but what i actually got was super helpful and understanding. so, thanks for that, really appreciate it.

edit: got it working, also, found a neat effect forgetting to reset the alpha value between frames

still am curious about the calculation difference though

Computers cannot compute accuracies too much. This is the same reason why $$0.1 + 0.2 = 0.30000000000000004$$.

This is intentional. Not a bug.

actually computers are perfectly capable of computing accurately to an arbitrary level of precision. try this. ive done this before in javascript, created arbitrary precision arithmetic functions that literally preform arithmetic the way you would by hand, digit by digit, add the carry, etc. this is besides the point. not the issue here. the issue is if i make a function add(a,b) {return a + b} yes i will get add(.1,.2) = .300000...4. so will snap. so will anyone. i want to know why preforming seemingly the same operations here is returning different results.

and this is in fact a bug. nobody thought 'hehehe watch im gonna make .1 and .2 = .30000000...4 instead of .3 for everyone forever' this is an error that we just deal with/workaround because i believe the tradeoff between (mostly) negligible precision error <-> ridiculous performance.


more appropriately, -25+sin(-189) in js returns -24.84356553495977. this version of snap is written in js. somewhere, -25 is stored as the sprites x position. -189 is stored too for y. so, sprite.x + sin(sprite.y) in theory will also = -24.84356553495977. its not. somewhere there is something else being done to the values so that -24.84356553495968 is returned instead of -24.84356553495977. i want to know what that something is.

See this website on why 0.1 + 0.2 is 0.30000000000000004: 0.30000000000000004.com

Also, see this:

i dont care. if im converting a snap project that adds two numbers to javascript and both implementations return .30000...4 for .1 + .2, i am happy. i need consistency not accuracy.

and will likely give exactly the same answer in any programming language.

^^ is my point!

"Intentional" is putting it strongly. We'd all be super happy if computers could get exact answers to arithmetic on real numbers.

We could easily improve the situation by representing real numbers inside the computer in base 10. Then problems such as 0.1+0.2 would come out exactly right. (If that sounds like an absurd idea, bear in mind that for a long time there were two kinds of computers: business computers, which used decimal arithmetic, and scientific computers, which used binary. The IBM System/360, which came out around my senior year of high school, so I guess 1964 or -65, was introduced with great fanfare as a revolutionary new design, because it included both binary and decimal arithmetic hardware, so you could use it for both kinds of problems! Of course this just meant that the IBM management didn't understand the idea of abstraction, which in this case means that the internal representation of data doesn't have to be the same as what the user sees.)

Another way to improve our ability to do arithmetic correctly is to avoid real numbers whenever possible, instead using exact rational arithmetic. So your example becomes 1/10 + 2/10, which gives an exact 3/10 as the result.

Alas, sometimes you want to know the circumference of a circle, and there's no exact rational representation of 𝜋. Nor of √2. Etc. So we have to find a way to do arithmetic on real numbers in computers.

There are different degrees of infiniteness. Strangely, although there are as many integers as rational numbers, there are way more real numbers. (Look it up.) As a result, even if we could represent infinitely many digits in the computer, that wouldn't be good enough to represent all the reals exactly. The problem is fundamental, not a bad design of any particular approach, such as floating point.

Edit: I was wrong about that. I should have said, we still couldn't get all the reals in our infinite computer. But also, it would take infinitely long to compute all those digits of even one irrational number.

This problem isn't really about floating point, but about the resolution of sprite positions. If you do the same CHANGE BY using variables X and Y instead of X POSITION and Y POSITION, you get the answer you're looking for.

This works:

But if you say

help-test script pic (3)

I'm not actually sure why sprite positions lose precision, but if you want repeatable computations you can't use them as variables. :~)

Hadda look it up. :~) Thank you! I really appreciate the compliment.

What I am is a teacher. I love teaching people stuff. That's why I'm here.

if you want repeatable computations you can't use them as variables.

what do you mean by this?

You can't rely on sprite positions as variables.

Semi-related but one of the technical staff or whatever "complimented" me because I spent a lot of time on the Berkeley website

I went to the media center because my Chromebook was being weird, and I had to tell one of the people there my name and she was like "Oh, you're that kid that spends an unusual amount of time on the Berkeley website", probably talking about Snap!, and I guess it didn't show the subdomain and only the root.

I can't wait for the staff to refer to me as "the Berkeley kid". I also spend quite a lot of time on the forums and the sites.

Half of my days are school, object show making, FORUM. then sleeping! :slight_smile:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.