4 ms·

What about: 4) It's not obvious how this bug could happen! Let's think about it!

by bdr 17y ago

swolchok 17y ago
Well, apparently, it was obvious. AFAICT, no one has come up with a better explanation than using IEEE floating point where bignums should be used, which I pointed out in my original comment.
- dreish 17y ago
  Except that neither double nor single precision IEEE floats behave the same way as whatever numbers Google is using.
  - swolchok 17y ago
    The algorithm probably first decides how to do the math and then does the math. EDIT: single-precision does behave this way: -bash-3.2$ cat precision.c #include <stdio.h> int main() { float f1 = 999999999999999; float f2 = 999999999999997; printf("%f\n", f1 - f2); return 0; } -bash-3.2$ gcc precision.c -bash-3.2$ ./a.out 0.000000 I am saying that if it's not consistent with single-precision across multiple inputs, there's probably code that looks at the numbers involved and decides what kind of numeric type to use to do the calculations. In this case, single-precision floating-point happens to be a bad choice. Second edit: replacing the 7 with a 6 still prints 0. The parent is right: something else is going on here. I like the theory espoused elsewhere in this discussion that it's a result of some truncation to avoid returning nonzero when the result should be zero.
    - gjm11 17y ago
      What exactly do you mean, and how does it make "using floating point arithmetic with insufficient precision" a viable explanation for this, given that none of the usual floating-point formats behave in this way?
- jey 17y ago
  The guy who was the maintainer of Google Calculator from 2005 to 2007 confirmed that this is the correct explanation. He said he wanted to switch it to use bignums, but wasn't able to (and not due to technical reasons). ZorbaTHut (http://mandible.net http://mandible.net) said: it's 80-bit ieee floats internally, but there's some specialized code to clamp it to zero when it looks like it ought to be zero. as far as I know it should otherwise behave exactly like 80-bit ieee (it wouldn't surprise me if the clamping code is being a little overzealous in this case)
  - Asmodeus 17y ago
    If the reason wasn't technical, what was the reason? The first thing that springs to my mind is that Google calculator is free, and more precision isn't.
deleted 17y ago
[deleted]

What about: 4) It's not obvious how this bug could happen! Let's think about it!

by bdr 17y ago

What about: 4) It's not obvious how this bug could happen! Let's think about it!

Well, apparently, it was obvious. AFAICT, no one has come up with a better explanation than using IEEE floating point where bignums should be used, which I pointed out in my original comment.

dreish 17y ago
Except that neither double nor single precision IEEE floats behave the same way as whatever numbers Google is using.
- swolchok 17y ago
  The algorithm probably first decides how to do the math and then does the math. EDIT: single-precision does behave this way: -bash-3.2$ cat precision.c #include <stdio.h> int main() { float f1 = 999999999999999; float f2 = 999999999999997; printf("%f\n", f1 - f2); return 0; } -bash-3.2$ gcc precision.c -bash-3.2$ ./a.out 0.000000 I am saying that if it's not consistent with single-precision across multiple inputs, there's probably code that looks at the numbers involved and decides what kind of numeric type to use to do the calculations. In this case, single-precision floating-point happens to be a bad choice. Second edit: replacing the 7 with a 6 still prints 0. The parent is right: something else is going on here. I like the theory espoused elsewhere in this discussion that it's a result of some truncation to avoid returning nonzero when the result should be zero.
  - gjm11 17y ago
    What exactly do you mean, and how does it make "using floating point arithmetic with insufficient precision" a viable explanation for this, given that none of the usual floating-point formats behave in this way?
jey 17y ago
The guy who was the maintainer of Google Calculator from 2005 to 2007 confirmed that this is the correct explanation. He said he wanted to switch it to use bignums, but wasn't able to (and not due to technical reasons). ZorbaTHut (http://mandible.net http://mandible.net) said: it's 80-bit ieee floats internally, but there's some specialized code to clamp it to zero when it looks like it ought to be zero. as far as I know it should otherwise behave exactly like 80-bit ieee (it wouldn't surprise me if the clamping code is being a little overzealous in this case)
- Asmodeus 17y ago
  If the reason wasn't technical, what was the reason? The first thing that springs to my mind is that Google calculator is free, and more precision isn't.

deleted 17y ago

[deleted]