Hacker News Reader

Comment by _cbsz | Hacker News Reader

Maybe I'm just getting incurably academic, but I think "I found a bug!" is not nearly as interesting as "I found a bug!" and one of:

1) It affects millions of people!

2) It affects large amounts of money!

3) It is a great example of a new or rare class of bug. Here's how you can avoid introducing similar bugs into your code! Here's how we can detect these things automatically! etc.

Here, the only thing that springs to mind is IEEE floating point being used internally by Google Calculator for some reason, which I find hard to believe. Where's the insight?

View on HN

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.

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) 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)

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.

Except that neither double nor single precision IEEE floats behave the same way as whatever numbers Google is using.

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.

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?

I agree. My first thought was "who cares?" After reading all the comments, my thought was "who cares?" Now, my thought is "who cares?"

Spoken like a true "business guy". It's technically interesting behavior.

BTW, bing does it right: http://www.bing.com/search?q=999999999999999+-+9999999999999...

Bing gets it wrong if you add enough digits:

http://www.bing.com/search?q=999999999999999999999999999+-+9...

As does the google calculator widget:

http://www.google.com/ig/directory?hl=en&url=www.google....

I was curious as to what caused this. Posting to HN seemed like the fastest way to get an answer.

Interestingly, you also created a top Google result for this search term (indexed in around 10 minutes):

http://www.google.com/search?hl=en&client=safari&rls...

Google loves Hacker News.

Not hard to get a page indexed with only 700 other competing pages. lol

http://www.google.com/search?q=700+other+competing

Clearly someone wasn't using 'bignum' when they should have.

Pretty sloppy to not even detect overflow on the input.

another one:

http://www.google.com/#q=999999999999999999+-+90000000000000...

It's not really overflow. It's more like insufficient precision.

Insufficient precision implies too little bits to store the number in.

These are unsigned integers, they could have been represented as integers in a 64 bit unsigned value, if the number of bits in the variable destined to hold the input is not enough and you keep on working as though there are that's overflow al right.

It should have simply thrown an error: operand too large.

I have a dark brown feeling that it won't be long before it does though :)

My definition of "overflow" is along the lines of "value is too big to be represented by said type". If they had been using integers, ok. But they're using floats, and floats can hold numbers bigger than that.

It all boils down to what type you consider the entries have, opposed to what Google considers.

I did not realize they use floats to represent all types, 64.64 would have been an excellent choice for this and would go a long way to solving the issue reported.

This bug has been there for years. So I don't think they'll fix it all that fast.

They use floats for everything, not ints.

That would explain it quite nicely, the decimal64 implementation of the ieee floating point data tops out at 16 digits.

edit: actually, it doesn't, the input above is 15 digits long.

...also known as Arithmetic underflow (http://en.wikipedia.org/wiki/Arithmetic_underflow)

The correct term is quantization, iirc.

I guess it's just a reminder not to trust a search engine with your fiduciary responsibilities?

http://www.brillig.com/debt_clock/

I think you still have a few orders of magnitude to go before that becomes a real problem.

I remember a programmer once griping that you still need to be careful with floats, and that double-precision still did not have neough significant digits to store the dollar to turkish lira conversion rate..

If you need floats you don't understand your problem ;)

unless you're doing realtime graphics

No, you can do realtime graphics just fine with fixed point arithmetic.

You can do nice matrix and vector math entirely in 16.16 fixed point. It's not as fast as having a co-processor, but there was a time that those were not standard items.

The problem is not with precision, but in using floats to represent money.

Why in the fuck would you try to do financial math with anything but fixed-point or rational numbers?

This is clearly a floating point precision problem. It happens when are no bits small enough on the mantissa to express the difference between the two values.

Check out: http://www.google.com/search?q=999999999999999+*+1 this overflows into the next integer as well.

In the early 90's the Pentium floating point error could fit your criteria:

http://www.cs.niu.edu/other/pentium.html

I remember taking the chip into Digital at the time. They replaced it for me.

Reply on news.ycombinator.com