51–60 of 107 posts
Earlier quoted context omitted.
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.
This is a pretty good description of what's (probably) going on: http://www.stata.com/statalist/archive/2002-10/msg00290.html
In Python: >>> 999999999999999 - 999999999999997 2L
The bug, in Python (needs more digits because Python's "float" is C's "double"): >>> float(999999999999999999) - float(999999999999999997) 0.0
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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..
Earlier quoted context omitted.
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'…
It all boils down to what type you consider the entries have, opposed to what Google considers.
Earlier quoted context omitted.
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.
Except that neither double nor single precision IEEE floats behave the same way as whatever numbers Google is using.
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
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.
Well you can also go somewhere meant for doing computations and get an accurate result. http://www.wolframalpha.com/input/?i=999999999999999+-+99999...
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.