Hacker News Reader

Comment by gfv | Hacker News Reader

I have a way simpler explanation. IEEE 754 double can only represent integers up to 2^53 without precision loss, so if you naively average two numbers greater than 2^52, you get an erroneous result.

It just so happens that 2^52 nanoseconds is a little bit over 52 days.

I've seen the same thing with AMD CPUs where they hang after ~1042 days which is 2^53 10-nanosecond intervals.

View on HN

This is incorrect. Very incorrect and disastrously so. Drop 0.3 in here: https://www.h-schmidt.net/FloatConverter/IEEE754.html

You can also drop 524535643, an integer clearly less than 2^53 and is off by 5.

This is even seen here:

    #include <stdio.h>

    int main() {
            float b = 524535643.0f;
            printf("%f", b);
            return 0;
    }

output: 524535648.000000

I was talking specifically about double-precision floats. Single-precision floats can represent every integer up to +-2^24.

Ah, missed that detail.

How could their comment possibly be "incorrect and disastrously so" unless the FAA is citing this thread for their investigation?

The comment said IEEE754 doubles can represent integers to 2^52. But I missed the double or assumed float. Floats cannot do that and it would be disastrous to assume so. For that matter, doubles also have some pretty big issues when you do operations on them (loss of precision), but as long as you are purely doing integer operations, it “should” be fine. A practical example with non-integers: 35 + -34.99

Having done exactly this math for GStreamer bindings in JavaScript (where the built in numeric types are double or nothing), this would also be my prime suspect.

Please email Boeing!

Seriously they should have posted here for some help!

Reply on news.ycombinator.com