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.
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)The first thing that springs to my mind is that Google calculator is free, and more precision isn't.
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.