Related: A fun video that illustrates floating-point precision by way of Super Mario 64:
Demystifying Floating Point Precision
11–20 of 57 posts
Re: Demystifying Floating Point Precision
#12I've stated some notes on Floats before, and I think this blogpost is pretty good overall. The one thing that trips up a lot of people (that wasn't mentioned in this post) is that Floats are non-associative. Try the following in Python (or whatever language that uses Doubles): >>> 1 + 1 + (2. * * 53) > 9007199254740994.0 >>> 1 + (1 + (2. * * 53)) > 9007199254740992.0 claytonjy noted a point of confusion, the above st…
The second equation confused me a bit as a math-first, cs-second person; looks like a commutative transform, not an associative one. The trick is one must already trust these ops are commutative. The second equation might be more clearly written as: >>> 1 + (1 + (2. * * 53)) to avoid hiding the associativity behind the assumption of commutativity.
You're right. Sorry for the confusion. I'll edit it to make it more clear.
Re: Demystifying Floating Point Precision
#13Related: A fun video that illustrates floating-point precision by way of Super Mario 64: https://youtu.be/9hdFG2GcNuA
I hate these text-on-picture-with-music videos. Even the robot-voice videos are better. I know it's using the Super Mario music, but still. It's like a blog post where you can't copy or paste anything, can't scroll back and forth, can't be cached or indexed, etc.
Re: Demystifying Floating Point Precision
#14I've stated some notes on Floats before, and I think this blogpost is pretty good overall. The one thing that trips up a lot of people (that wasn't mentioned in this post) is that Floats are non-associative. Try the following in Python (or whatever language that uses Doubles): >>> 1 + 1 + (2. * * 53) > 9007199254740994.0 >>> 1 + (1 + (2. * * 53)) > 9007199254740992.0 claytonjy noted a point of confusion, the above st…
It gets even worse: (1 + 2 ^ 53) - 2 ^ 53 evaluates to 0 while 1 + (2 ^ 53 - 2 ^ 53) evaluates to 1 (the correct result), which means that even the operation of adding three floating point numbers has unbounded relative error in the general case.
This is a great source of frustration in computational geometry, where this turns from a quantitative issue to a qualitative one, since if we get the sign of an expression wrong our data structures might no longer reflect the actual topology of the problem.
Re: Demystifying Floating Point Precision
#15Worth a read if you haven't seen it: “What every computer scientist should know about floating point arithmetic”. This includes a better discussion of all the points in the blog post.
https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.h...
Re: Demystifying Floating Point Precision
#16Related: A fun video that illustrates floating-point precision by way of Super Mario 64: https://youtu.be/9hdFG2GcNuA
I hate these text-on-picture-with-music videos. Even the robot-voice videos are better. I know it's using the Super Mario music, but still. It's like a blog post where you can't copy or paste anything, can't scroll back and forth, can't be cached or indexed, etc.
He has some videos that are commentated by voice, but for some reason he finds doing the recordings very stressful, so most of his content is unfortunately on his 'uncommentated' channel. I agree it would be nice to have the voice-overs
Re: Demystifying Floating Point Precision
#17Related: A fun video that illustrates floating-point precision by way of Super Mario 64: https://youtu.be/9hdFG2GcNuA
A video game demonstration really helps understand how the coarseness of floats can introduce all kinds of strange bugs.
Re: Demystifying Floating Point Precision
#18I've always thought that floats should be accompanied with a precision value specifying the number of significant digits. Ideally updated by hardware in the same operation.
All floating point code has subtle bugs if you don't track error accumulation.
Re: Demystifying Floating Point Precision
#19Key point that takes some time to sink in: there are only 2^32 32 bit floats in total. Meaning that you can easily enumerate them all.
Re: Demystifying Floating Point Precision
#20I've always thought that floats should be accompanied with a precision value specifying the number of significant digits. Ideally updated by hardware in the same operation. All floating point code has subtle bugs if you don't track error accumulation.
Wouldn't that be closer to interval arithmetic?