Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

9999999999999999.0 – 9999999999999998.0

geocar.sdf1.org

Post reply on HN
Print view View original

31–40 of 83 posts

Re: 9999999999999999.0 – 9999999999999998.0

#31

Post by quietbritishjim »

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.

> What's really surprising is that this number is only ~16 million in single precision floats.

What does this mean? Surely even single precision floating point can represent a number far closer to the original than 16 million? Edit: It appears the closest number in single precision is 9007199000000000.0

Edit2: Oh I see: you mean that the first number that cannot be represented precisely by a single-precision float is ~16 million.

Re: 9999999999999999.0 – 9999999999999998.0

#32

Post by adgjlsfhk1 »

roessland wrote: post #20

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…

It's not different rounding modes, but different floating point formats. Google is doing something very weird that is also base 10 related. Not sure about TCL.

Re: 9999999999999999.0 – 9999999999999998.0

#33

Post by Retr0id »

The page never explicitly states what the right answer is, but based on the output of their suggested "correct" perl, we can infer that they expect 1.

This is just me being idiosyncratic I guess, but if I see a number with a decimal place, I default to interpreting it as an fp64 unless otherwise specified - which yields a "correct" answer of 2.0 (which is not an answer I can get to in my head, admittedly)

If the question-asker wanted integer arithmetic, they'd have left off the ".0", and if they wanted something other than fp64 roundTiesToEven they should've been more explicit :P

Re: 9999999999999999.0 – 9999999999999998.0

#34

Post by GTP »

Retr0id wrote: post #33

The page never explicitly states what the right answer is, but based on the output of their suggested "correct" perl, we can infer that they expect 1. This is just me being idiosyncratic I guess, but if I see a number with a decimal place, I default to interpreting it as an fp64 unless otherwise specified - which yields a "correct" answer of 2.0 (which is not an answer I can get to in my head, admittedly) If the ques…

Could you please explain me why 2 would be the correct answer?

Re: 9999999999999999.0 – 9999999999999998.0

#35

Post by ashton314 »

Emacs Calculator with high precision will get you what you need (`M-x calc RET P 20 RET 9999999999999999.0 RET 9999999999999998.0 RET -` gives you `1.`)

Definitely keeping this example in my back pocket for explaining to people why floating point is not what you think it is.

Re: 9999999999999999.0 – 9999999999999998.0

#36

Post by tzot »

adgjlsfhk1 wrote: post #32
roessland wrote: post #20

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…

It's not different rounding modes, but different floating point formats. Google is doing something very weird that is also base 10 related. Not sure about TCL.

TCL does for quite some years now use real integers (unbounded size) and floats (float8) whenever possible. By the way, the article does not specify versions of languages, so:

    $ tclsh
    % puts $tcl_version
    8.6
    % expr "9999999999999999.0-9999999999999998.0"
    2.0

Re: 9999999999999999.0 – 9999999999999998.0

#37

Post by Retr0id »

GTP wrote: post #34
Retr0id wrote: post #33

The page never explicitly states what the right answer is, but based on the output of their suggested "correct" perl, we can infer that they expect 1. This is just me being idiosyncratic I guess, but if I see a number with a decimal place, I default to interpreting it as an fp64 unless otherwise specified - which yields a "correct" answer of 2.0 (which is not an answer I can get to in my head, admittedly) If the ques…

Could you please explain me why 2 would be the correct answer?

Parsing the provided numbers to two IEEE 754 double-precision floats, and then subtracting them, yields 2.0 (due to rounding)

In particular, 9999999999999999.0 rounds up to 10000000000000000.0

(note, this behavior depends on the rounding mode, https://en.wikipedia.org/wiki/IEEE_754#Rounding_rules )

Re: 9999999999999999.0 – 9999999999999998.0

#38

Post by roessland »

Drive-by wrote: post #25

Postgres and SQL: postgres=# select 9999999999999999.0 - 9999999999999998.0 as result; result -------- 1.0

The default PG type, `numeric`, has almost arbitary precision.

    select pg_typeof(9999999999999999.0); 
    -- numeric

    select 9999999999999999.0::double precision 
           - 9999999999999998.0::double precision; 
    -- 2
More interesting perhaps, is mixing up `real` (aka float32) with `numeric`:

    select 9999999999999999.0::real - 9999999999999998.0;
    -- 272564226 (?! can anyone explain?)

    select 9999999999999999.0::real;
    -- 10000000300000000
Wat
Post reply on HN