9999999999999999.0 – 9999999999999998.0 • Hacker News Board

Re: 9999999999999999.0 – 9999999999999998.0

#11

Post by nine_k » Thu, Jan 11, 2024, 4:49 PM UTC

fouronnes3 wrote: post #4

IEEE754 is always fun. 9007199254740993 is the first integer that cannot be represented as a double precision float. So in python: >>> 9007199254740993.0 9007199254740992.0 What's really surprising is that this number is only ~16 million in single precision floats.

Floating point is all about relative precision. f64 gives you 53 bits of mantissa, so you have precision of about 1.1e-16, almost 16 decimal places. But the 17th place, and sometimes the 16th place, gets clobbered.

Integers have absolute precision, at the expense of either range (say, i64) or arbitrarily growing size.

Re: 9999999999999999.0 – 9999999999999998.0

#12

Post by foobiekr » Thu, Jan 11, 2024, 4:51 PM UTC

QuadrupleA wrote: post #2

Floating point 101. And it almost never matters.

You say that, and then an army of idiots out in the real world continues to use floats for financial data and other large integers.

I ran into a site that broke because they were using 64b unix nanotime in Javascript and comparing values which were truncated. You see this in js, python, etc. constantly.

Re: 9999999999999999.0 – 9999999999999998.0

#13

Post by jsharpe » Thu, Jan 11, 2024, 4:52 PM UTC

Volundr wrote: post #5

QuadrupleA wrote: post #2

Floating point 101. And it almost never matters.

> And it almost never matters. I take issue with this. Drift from floating point inaccuracies can compound quickly and dramatically affect results. Sure if you're just looping over a 1000 item list, it's not going to matter that JavaScript is representing that as a float/double, but in a wide variety of contexts, such as anything to do with money, it absolutely does matter.

Another example is open world games. They have to keep world coordinates centered on the player because for large worlds, the floating point inaccuracy in the far reaches of the world starts to really matter. An example of a game that does this is Outer Wilds.

Re: 9999999999999999.0 – 9999999999999998.0

#14

Post by v8xi » Thu, Jan 11, 2024, 4:53 PM UTC

Was curious what chatGPT would say:

The result of subtracting 9999999999999998.0 from 9999999999999999.0 is 2.0. This result is due to the limitations in the precision of floating-point arithmetic in computers. When dealing with very large numbers, the precision can be lost, leading to such unexpected results.

I suppose this must be in its training set.

Re: 9999999999999999.0 – 9999999999999998.0

#15

Post by mspreij » Thu, Jan 11, 2024, 4:58 PM UTC

nashashmi wrote: post #3

The GoLang bit tells me that the author is trying to show wrong answers only. And that is ok because this needs to be said out loud. I wonder if there is a way to fool Wolfram in giving the wrong answer. Or ChatGPT?

ChatGPT 4 pondered for a while, then started "Analyzing..", and eventually "Finished analyzing" (all following verbatim output):

python 9999999999999999.0 - 9999999999999998.0 Result 2.0

The result of the calculation 9999999999999999.0−9999999999999998.0 is 2.0.

This result may seem counterintuitive, but it's due to how floating-point numbers are represented and handled in computing. Floating-point arithmetic can introduce small rounding errors, especially with very large numbers, as precision is limited. In this case, the precision required to represent these large numbers exactly is beyond what typical floating-point representations (like IEEE 754 double precision) can handle, leading to a slight error in the calculation.

Re: 9999999999999999.0 – 9999999999999998.0

#16

Post by [deleted] » Thu, Jan 11, 2024, 4:59 PM UTC

jsharpe wrote: post #13

Volundr wrote: post #5

Earlier quoted context omitted.

> And it almost never matters. I take issue with this. Drift from floating point inaccuracies can compound quickly and dramatically affect results. Sure if you're just looping over a 1000 item list, it's not going to matter that JavaScript is representing that as a float/double, but in a wide variety of contexts, such as anything to do with money, it absolutely does matter.

Another example is open world games. They have to keep world coordinates centered on the player because for large worlds, the floating point inaccuracy in the far reaches of the world starts to really matter. An example of a game that does this is Outer Wilds.

[deleted]

Re: 9999999999999999.0 – 9999999999999998.0

#17

Post by Cyphus » Thu, Jan 11, 2024, 5:00 PM UTC

> That Go uses arbitrary-precision for constant expressions seems dangerous to me.

I'm somewhat baffled by this statement. If a Go program compared a constant expression float against a runtime computed float, it could have unexpected results, but comparing floats in general is dangerous. I don't see how this language quirk increases that danger in a meaningful way.

Re: 9999999999999999.0 – 9999999999999998.0

#18

Post by nashashmi » Thu, Jan 11, 2024, 5:01 PM UTC

mspreij wrote: post #15

nashashmi wrote: post #3

The GoLang bit tells me that the author is trying to show wrong answers only. And that is ok because this needs to be said out loud. I wonder if there is a way to fool Wolfram in giving the wrong answer. Or ChatGPT?

ChatGPT 4 pondered for a while, then started "Analyzing..", and eventually "Finished analyzing" (all following verbatim output): python 9999999999999999.0 - 9999999999999998.0 Result 2.0 The result of the calculation 9999999999999999.0−9999999999999998.0 is 2.0. This result may seem counterintuitive, but it's due to how floating-point numbers are represented and handled in computing. Floating-point arithmetic can int…

> result may seem counterintuitive

does it say this out loud?

Re: 9999999999999999.0 – 9999999999999998.0

#19

Post by vaicorinthians » Thu, Jan 11, 2024, 5:01 PM UTC

tromp wrote: post #10

bc -l is my standard command-line tool for arbitrary precision calculations (-l not needed here but handy for functions like sqrt(), e(), and log l() ): $ bc -l bc 1.06 Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. 9999999999999999.0 - 9999999999999998.0 1.0

bc is my calculator for pretty much everything for decades now. lol

Re: 9999999999999999.0 – 9999999999999998.0

#20

Post by roessland » Thu, Jan 11, 2024, 5:04 PM UTC

Here's a great introduction to floating-point numbers: https://tobydriscoll.net/fnc-julia/intro/floating-point.html

The next representable number after 9999999999999998.0 is 1.0e16. 9999999999999999.0 is not exactly representable in IEEE 754 floats, and will be rounded up or down.

The difference between 0.0 and 2.0 in the table is likely due to different rounding modes. I'm curious how different languages end up with different rounding modes. Is that possible to configure?

    julia> 9999999999999999.0 - 9999999999999998.0
    2.0

    julia> -9.999999999999999 + 9.999999999999998
    0.0