3 ms·

Tried it in Numbers and they both say 0.0000000000000000555111512312578 EDIT: Numbers is http://www.apple.com/mac/numbers/ http://www.apple.com/mac/numbers/

bronson 11y ago
LibreOffice Calc shows both as 0.
- sdegutis 11y ago
  Try changing the cell to show as many floating points as possible (in Numbers it was to set it to "Automatic").
  - DiThi 11y ago
    Sill both zero (dot many zeroes).
    - sdegutis 11y ago
      I saw the same thing in Numbers until I expanded the field to a larger width, which revealed the non-zero digits at the very end of all the zeroes.
ajross 11y ago
That... is not a known hardware floating point representation. There are way too many digits. This is a just-plain-buggy conversion routine I'm guessing? What is Numbers, and why isn't it using a proper arbitrary precision library if it doesn't want to use doubles? Edit: sorry, my brain was still reading the leading 0.3 from the linked article. There is indeed nothing wrong with that representation except the nonstandard leading zeroes.
- striking 11y ago
  Apple's brand of Excel.
- cowsandmilk 11y ago
  uh, perl gives exactly the same answer as Numbers > perl -E 'say .1 + .2 - .3' 5.55111512312578e-17 And python actually gives one more digit than Numbers > python -c 'print(repr(.1 +.2 -.3))' 5.551115123125783e-17 So, I'm not sure why you are claiming "there are way too many digits" and that Numbers is doing something wrong.
- marcosdumay 11y ago
  What? No, it's a perfectly valid floating point number, represented in a way that lay people might understand. Those zeros are not part of the mantissa.
- merpnderp 11y ago
  A double can hold 15-17 significant base 10 digits. The exponent can be +-10^308 (11 bits for the exponent, 52 bits for the fraction, 1 bit for the sign).
  - ajross 11y ago
    Yes yes yes, I know how to represent an IEEE value. It was an interpretation error: the linked article shows a zillion variants of numbers with a leading significant of 0.3 (i.e. all the leading zeros are significant) while the posted string above did not.
- gerry_shaw 11y ago
  Postgres gives the same response. # select 0.1::float + 0.2::float - 0.3::float; ---------------------- 5.55111512312578e-17

bronson 11y ago

LibreOffice Calc shows both as 0.

sdegutis 11y ago
Try changing the cell to show as many floating points as possible (in Numbers it was to set it to "Automatic").
- DiThi 11y ago
  Sill both zero (dot many zeroes).
  - sdegutis 11y ago
    I saw the same thing in Numbers until I expanded the field to a larger width, which revealed the non-zero digits at the very end of all the zeroes.

ajross 11y ago

That... is not a known hardware floating point representation. There are way too many digits. This is a just-plain-buggy conversion routine I'm guessing? What is Numbers, and why isn't it using a proper arbitrary precision library if it doesn't want to use doubles? Edit: sorry, my brain was still reading the leading 0.3 from the linked article. There is indeed nothing wrong with that representation except the nonstandard leading zeroes.

striking 11y ago
Apple's brand of Excel.
cowsandmilk 11y ago
uh, perl gives exactly the same answer as Numbers > perl -E 'say .1 + .2 - .3' 5.55111512312578e-17 And python actually gives one more digit than Numbers > python -c 'print(repr(.1 +.2 -.3))' 5.551115123125783e-17 So, I'm not sure why you are claiming "there are way too many digits" and that Numbers is doing something wrong.
marcosdumay 11y ago
What? No, it's a perfectly valid floating point number, represented in a way that lay people might understand. Those zeros are not part of the mantissa.
merpnderp 11y ago
A double can hold 15-17 significant base 10 digits. The exponent can be +-10^308 (11 bits for the exponent, 52 bits for the fraction, 1 bit for the sign).
- ajross 11y ago
  Yes yes yes, I know how to represent an IEEE value. It was an interpretation error: the linked article shows a zillion variants of numbers with a leading significant of 0.3 (i.e. all the leading zeros are significant) while the posted string above did not.
gerry_shaw 11y ago
Postgres gives the same response. # select 0.1::float + 0.2::float - 0.3::float; ---------------------- 5.55111512312578e-17