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

999999999999999 - 999999999999997

google.com

Post reply on HN
Print view View original

71–80 of 107 posts

Re: 999999999999999 - 999999999999997

#71

Post by gjm11 »

This is definitely not just a matter of using double where something longer would have been better. 999999999999999 and 999999999999997 are both exactly representable as 64-bit IEEE floating-point numbers (i.e., doubles).

They're not using single-precision floats either; with one 9 fewer in each number, everything's fine, but those numbers are way out of range for 32-bit IEEE floats.

Doesn't look like fixed-precision decimals, either: reduce the second number by 1 and you correctly get a difference of 3.

Re: 999999999999999 - 999999999999997

#72

Post by gjm11 »

_cbsz wrote: post #58
dreish wrote: post #51

Earlier quoted context omitted.

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 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 prob…

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?

Re: 999999999999999 - 999999999999997

#73

Post by [deleted] »

mustpax wrote: post #23
_cbsz wrote: post #3

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 t…

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.

[deleted]

Re: 999999999999999 - 999999999999997

#74

Post by gjm11 »

gjm11 wrote: post #71

This is definitely not just a matter of using double where something longer would have been better. 999999999999999 and 999999999999997 are both exactly representable as 64-bit IEEE floating-point numbers (i.e., doubles). They're not using single-precision floats either; with one 9 fewer in each number, everything's fine, but those numbers are way out of range for 32-bit IEEE floats. Doesn't look like fixed-precision…

Tweaking that second number, I find that when the difference is 2 or less we get 0, but otherwise we get the right answer. More evidence that it's not simply a FP imprecision problem. Further, if I approximately halve them both (just change the initial 9 to a 4) then a difference of 1 or less produces 0 and other results are correct.

I think what's going on is more likely this: whoever implemented this wanted to avoid giving nonzero answers to calculations whose correct answer is zero, and therefore put in some sort of deliberate truncation somewhere. (It's not clear to me exactly what -- maybe every addition or subtraction that produces an answer much much smaller than its inputs gets clamped to 0, or something.)

I don't think the truncation is happening purely at the output stage: if I as it to do the original calculation and multiply the result by 100, e.g., I still get 0. (I had to write it like that because otherwise HN's asterisks-mean-italics hack scrambles it. Even though the supposedly matching asterisk is in a different paragraph. PG, if you're reading this, I'd love it if you were to change that behaviour.)

In other words, I think we're seeing an unfortunate effect of the same feature that makes it say that cos(2*atan(1)) is 0 rather than reporting it as about 6.123 x 10^-17 (the actual result in IEEE doubles).

Re: 999999999999999 - 999999999999997

#75

Post by calcnerd256 »

jacquesm wrote: post #55
joshu wrote: post #54

Earlier quoted context omitted.

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

Re: 999999999999999 - 999999999999997

#76

Post by adrianwaj »

_cbsz wrote: post #3

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 t…

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.

Re: 999999999999999 - 999999999999997

#77

Post by calcnerd256 »

randallsquared wrote: post #32
jacquesm wrote: post #28

Earlier quoted context omitted.

I think I could have done without those mental images, thank you.

The ability to ignore and avoid thinking about certain things is essential when visiting 4chan. If you practice, you can read sentences like the above without having mental images of the described event. More advanced filters can prevent you from thinking about it with imagery even after seeing something you wish you hadn't seen. ;)

I would rather have never been to /b/ and not have that ability and miss out on all the counterculture, because that ability is also a curse.

Re: 999999999999999 - 999999999999997

#78

Post by calcnerd256 »

bdr wrote: post #68
teeja wrote: post #66

Is there anything that can do infinity - (infinity-1)?

Even in non-standard models of arithmetic, where you could use infinity as an operand, the value of that expression would have to be undefined (not 1, as you seem to expect).

What about limit as x goes to infinity of x - (x - 1)? We do the algebra first, right? Now, that's a special case of y - (x - 1) where y = x, so can we get a different residue by going about the limit in two dimensions?

Re: 999999999999999 - 999999999999997

#79

Post by jacquesm »

calcnerd256 wrote: post #75
jacquesm wrote: post #55

Earlier quoted context omitted.

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.

Re: 999999999999999 - 999999999999997

#80

Post by gloob »

Evgeny wrote: post #70
bdr wrote: post #68

Earlier quoted context omitted.

Even in non-standard models of arithmetic, where you could use infinity as an operand, the value of that expression would have to be undefined (not 1, as you seem to expect).

Maybe we could just define "infinity = 999999" or something like that ...

Maybe we could just define "zero = 123456789" or something like that while we're at it. If we're going to break math we may as well go whole hog.
Post reply on HN