999999999999999 - 999999999999997

http://www.google.com/search?client=safari&rls=en-us&q=999999999999999+-+999999999999997&ie=UTF-8&oe=UTF-8

by unalone • 17 years ago

185 101 17 years ago

_cbsz4• 17 years ago

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?

kevindication• 17 years ago

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

jacquesm10• 17 years ago

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

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

bdr2• 17 years ago

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

_cbsz4• 17 years 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.

unalone6• 17 years ago

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

jacquesm10• 17 years ago

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

bd2• 17 years ago

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

mustpax• 17 years ago

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.

mid• 17 years ago

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

nostrademons• 17 years ago

Bing gets it wrong if you add enough digits:

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

frossie• 17 years ago

As does the google calculator widget:

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

DanielStraight• 17 years ago

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

jey2• 17 years ago

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

adrianwaj• 17 years ago

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.

keltecp11• 17 years ago

I just want to know why you were even trying to calculate that figure in the first place?

unalone6• 17 years ago

I found it on 4chan.

profquail• 17 years ago

I don't even want to know why it was posted there...

icey• 17 years ago

This is a pretty good description of what's (probably) going on:

http://www.stata.com/statalist/archive/2002-10/msg00290.html

dreish3• 17 years ago

Except that the number of digits in this case is only 14.

teeja3• 17 years ago

... or so ...

RyanMcGreal• 17 years ago

In Python:

    >>> 999999999999999 - 999999999999997
    2L

_cbsz4• 17 years ago

The bug, in Python (needs more digits because Python's "float" is C's "double"):

    >>> float(999999999999999999) - float(999999999999999997)
    0.0

dreish3• 17 years ago

Not the same bug. Try chopping off a nine from each number, first in the above in Python, and then in the Google version.

bfung• 17 years ago

Out of curiosity...

  C:\>ruby --version
  ruby 1.8.6 (2008-08-11 patchlevel 287) [i386-mswin32]

  C:\>irb
  irb(main):001:0> 999999999999999 - 999999999999997
  => 2
  irb(main):002:0> 9999999999999999 - 9999999999999997
  => 2
  irb(main):003:0> 999999999999999.0 - 999999999999997.0
  => 2.0
  irb(main):004:0> 9999999999999999.1 - 9999999999999997.1
  => 2.0

martythemaniak• 17 years ago

Wolfram Alpha tells me the answer is two :p

apotheon• 17 years ago

. . . but it's copyrighted, so you're not allowed to tell anyone.

eru3• 17 years ago

That's fair use.

briancray• 17 years ago

lol

assemble• 17 years ago

indeed

datums• 17 years ago

999 999 999 999 999 - 999 999 999 999 996 = 3 + or - 2 margin of error

Que• 17 years ago

Well you can also go somewhere meant for doing computations and get an accurate result.

http://www.wolframalpha.com/input/?i=999999999999999+-+99999...

nixy• 17 years ago

999 999 999 - 999 999 997 = 2 according to the calculator widget on the Dashboard in OS X 10.5

zeantsoi• 17 years ago

MS Excel had a similar issue (though probably an unrelated bug) a while back that caused a furor:

http://www.appscout.com/2007/10/excel_bug_exterminated.php

Imagine being the accountant who learned about this too late...

prakash• 17 years ago

I bet the guys at blekko don't have this problem when they launch.

http://www.skrenta.com/2008/04/microsoft_bias_in_msn_search_...

joubert2• 17 years ago

Obviously not using Lisp on the back-end.

uninverted• 17 years ago

I like Lisp too, but there's nothing especially accurate about it's arithmetic that you can't get in other civilized languages.

joubert2• 17 years ago

http://gigamonkeys.com/book/numbers-characters-and-strings.h...

One of the reasons Lisp is a nice language for math is its numbers behave more like true mathematical numbers than the approximations of numbers that are easy to implement in finite computer hardware. For instance, integers in Common Lisp can be almost arbitrarily large rather than being limited by the size of a machine word.3 And dividing two integers results in an exact ratio, not a truncated value. And since ratios are represented as pairs of arbitrarily sized integers, ratios can represent arbitrarily precise fractions.4

On the other hand, for high-performance numeric programming, you may be willing to trade the exactitude of rationals for the speed offered by using the hardware's underlying floating-point operations. So, Common Lisp also offers several types of floating-point numbers, which are mapped by the implementation to the appropriate hardware-supported floating-point representations.5 Floats are also used to represent the results of a computation whose true mathematical value would be an irrational number.

Finally, Common Lisp supports complex numbers--the numbers that result from doing things such as taking square roots and logarithms of negative numbers. The Common Lisp standard even goes so far as to specify the principal values and branch cuts for irrational and transcendental functions on the complex domain.

Andys• 17 years ago

Like Ruby.

Whippet• 17 years ago

On my HP48X rpn calculator I get = 0

The HP35 scientific calculator also give 0 as an answer.

wierd.

teeja3• 17 years ago

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

bdr2• 17 years ago

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

Evgeny• 17 years ago

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

calcnerd2565• 17 years ago

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?

teeja3• 17 years ago

Yeah ... I was suggesting that a more sophisticated algorithm for arithmetic on very large integers could eliminate substantial similarities, leaving the 'zone of difference'. A limited 'bit window' needs to be more versatile.

For example, a while back a man got a bill for $35 billion ... that wouldn't happen with more intelligence built into routines. (OUR minds look at 999...999 and 999...997 and see quickly what can be eliminated.)

gjm113• 17 years ago

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.

gjm113• 17 years ago

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

perekk• 17 years ago

Rebol 2:

>> 999999999999999 - 999999999999997 == 2.0

Rebol 3:

>> 999999999999999 - 999999999999997 == 2

kirubakaran2• 17 years ago

Well, they have fixed it.

bmunro• 17 years ago

Nope, still equals zero.

kirubakaran2• 17 years ago

Oops my mistake!

steiger• 17 years ago

in bash:

bash-3.1$ echo "(999999999999999 - 999999999999997)" | bc 2

mace• 17 years ago

IEEE 754 double precision can represent numbers with about 16 decimal digits of precision, however Google calculator (from anecdotal evidence) seems to only reliably represent numbers with 14 of precision (ex. http://www.google.com/search?q=99999999999999+-+999999999999...)

Interestingly, for pure decimal operations it seems some other floating point representation is used. For example, http://www.google.com/search?q=1.0+-+0.2+-+0.2+-+0.2+-+0.2+-... returns mathematically correct result of zero. If double precision were being used it should return the mathematically incorrect result of 0.0000000000000000555 because of floating point representations errors.

qeorge• 17 years ago

Both Yahoo[1] and Bing[2] get it right.

[1] http://search.yahoo.com/search;_ylt=A0geu.i5PZNKqSoAurJXNyoA... [2] http://www.bing.com/search?q=999999999999999+-+9999999999999...

psyklic• 17 years ago

Here is what seems to have happened: Note that whenever the answer is not accurate, Google uses scientific notation. For example, 1e15 + 30 = 1.0 × 10^15. We accept this as true because Google only claims it is true to two sig figs.

However, in this case, Google means to say 0.0 × 10^15, indicating two sig figs of accuracy. Google's mistake is probably that the internal notation used does not allow it to distinguish between "0" and "0.0 x 10^15", and so it does not report that the result is only accurate to two sig figs as it should.

So, if Google somehow reports the "zero" result in scientific notation with two sig figs, then it will be consistent with the rest of their calculator and clear that it may not be an accurate result.

999999999999999 - 999999999999997

Related Stories