Demystifying Floating Point Precision • Hacker News Board

Re: Demystifying Floating Point Precision

#51

Post by chillingeffect » Thu, Nov 23, 2017, 4:30 AM UTC

katastic wrote: post #25

nerdponx wrote: post #13

Earlier quoted context omitted.

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.

Guy did it for free man. Give him a little slack. He's not even a programmer. He does Mario speed runs. He didn't post his video here, someone else did. And I absolutely disagree with the "Robot voice would be better." That's horrific.

i don't think he's picking on the authors themselves but on the broader problem:

How to make decent auto-play presentations on the web.

most of us hate it when scrolling gets broken. many of us like to simply watch a lecture go by with interaction, e.g. for deeper contemplation. many of us would like to hear the lecture.

stuffing it into a video is tradeoff.

this is just a typical problem of a highly-mediated era: we have the core information that can be rendered or published across numerous formats: book, blog post, tweets, video, google slide presentation, etc., etc. How to deliver the information to all formats, to be everything to everyone?

Re: Demystifying Floating Point Precision

#52

Post by [deleted] » Thu, Nov 23, 2017, 5:05 AM UTC

slededit wrote: post #18

I'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.

[deleted]

Re: Demystifying Floating Point Precision

#53

Post by [deleted] » Thu, Nov 23, 2017, 5:18 AM UTC

zokier wrote: post #20

slededit wrote: post #18

I'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?

[deleted]

Re: Demystifying Floating Point Precision

#54

Post by madez » Thu, Nov 23, 2017, 7:11 AM UTC

gilbetron wrote: post #45

Years ago I created a solar system simulation for education called the Astronomicon. It was a fascinating education for me, not only about Astronomy and our solar system, but about floating point precision and general numerical stability issues. The problem really showed up with Pluto (back then a planet ;) ). Using 32 bits, a floating point seemed fine, except when you started up the simulation and saw pluto jumping…

Fixed precision floating point arithmetic is useful when you work over a large range of numbers and care about relative accuracy. That makes them also useful when the range is not known. However, the range is not irrelevant. Violating the allowed range can lead to bad accuracy, and shifting the numbers via a factor into the limitations can improve accuracy. From what you say, this happened in your case; the numbers got too small and you shifted them into the supported range, which is 2^(−126) to (1 − 2^(−24)) × 2^128 for IEEE 754-2008 32 bit numbers.

Re: Demystifying Floating Point Precision

#55

Post by madez » Thu, Nov 23, 2017, 7:41 AM UTC

Floating point numbers are suboptimal to represent timers. They use more bits than needed, aren't accurate on the bits they use, and require more effort for operations.

Unsigned integers are better to represent timers. If the accuracy is 1/30s as in the example, then with a 32 bit unsigned integer you could cover over 55 days with perfect numerical accuracy and minimal computational effort. With 32 bit floating point numbers you get only 6 days, while needing to worry about accuracy and higher computational demand. At 64 bits it is 649936019 years for unsigned integers vs 8925512 years for floating point. If your game doesn't depend on state that is longer ago than the time covered, then using unsigned integers allows unlimited runtime.

Don't blindly use floats.

Re: Demystifying Floating Point Precision

#56

Post by pjc50 » Thu, Nov 23, 2017, 12:24 PM UTC

madez wrote: post #55

Floating point numbers are suboptimal to represent timers. They use more bits than needed, aren't accurate on the bits they use, and require more effort for operations. Unsigned integers are better to represent timers. If the accuracy is 1/30s as in the example, then with a 32 bit unsigned integer you could cover over 55 days with perfect numerical accuracy and minimal computational effort. With 32 bit floating point…

Floating point numbers are terrible at representing times and money quantities. Which is a shame given that Excel does it that way..

Re: Demystifying Floating Point Precision

#57

Post by taejo » Thu, Nov 23, 2017, 1:46 PM UTC

gilbetron wrote: post #45

Years ago I created a solar system simulation for education called the Astronomicon. It was a fascinating education for me, not only about Astronomy and our solar system, but about floating point precision and general numerical stability issues. The problem really showed up with Pluto (back then a planet ;) ). Using 32 bits, a floating point seemed fine, except when you started up the simulation and saw pluto jumping…

Half of all floating-point values are between -1 and 1. Half of the remaining values have magnitude between 1 and 2. And so on... If we represent positions in kilometers, and we're talking about a solar system with radius on the order of a billion kilometers in diameter, and it becomes clear that we're wasting almost all of those floating point bits!