9999999999999999.0 – 9999999999999998.0 • Hacker News Board

9999999999999999.0 – 9999999999999998.0

#1

Post by tosh » Thu, Jan 11, 2024, 2:21 PM UTC

9999999999999999.0 – 9999999999999998.0
geocar.sdf1.org

Re: 9999999999999999.0 – 9999999999999998.0

#2

Post by QuadrupleA » Thu, Jan 11, 2024, 4:29 PM UTC

Floating point 101. And it almost never matters.

Re: 9999999999999999.0 – 9999999999999998.0

#3

Post by nashashmi » Thu, Jan 11, 2024, 4:37 PM UTC

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?

Re: 9999999999999999.0 – 9999999999999998.0

#4

Post by fouronnes3 » Thu, Jan 11, 2024, 4:38 PM UTC

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.

Re: 9999999999999999.0 – 9999999999999998.0

#5

Post by Volundr » Thu, Jan 11, 2024, 4:43 PM UTC

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.

Re: 9999999999999999.0 – 9999999999999998.0

#6

Post by francisofascii » Thu, Jan 11, 2024, 4:43 PM UTC

QuadrupleA wrote: post #2

Floating point 101. And it almost never matters.

For me, I encounter a floating point bug/issue every 4 years of so. So "almost never" sounds about right to me.

Re: 9999999999999999.0 – 9999999999999998.0

#7

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

QuadrupleA wrote: post #2

Floating point 101. And it almost never matters.

Not just floating point, but 64-bit IEEE 754 specifically. The last few bits of the mantissa are not sufficient to represent the last decimal digit exactly. 80 bits would suffice for this particular example, but would fail similarly with a longer mantissa.

BTW this is one of the reasons why you should never represent money as a float, except when making a rough estimate. Another, bigger reason is that 0.1 is an infinite repeating fraction in binary, so it can't be represented exactly.

Re: 9999999999999999.0 – 9999999999999998.0

#8

Post by beretguy » Thu, Jan 11, 2024, 4:44 PM UTC

Moral of the story: we all should switch to programming in Perl6.

Re: 9999999999999999.0 – 9999999999999998.0

#9

Post by t1234s » Thu, Jan 11, 2024, 4:47 PM UTC

php > echo 9999999999999999.0 - 9999999999999998.0; 2

Re: 9999999999999999.0 – 9999999999999998.0

#10

Post by tromp » Thu, Jan 11, 2024, 4:47 PM UTC

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