Well, they have fixed it.
Nope, still equals zero.
Oops my mistake!
999999999999999 - 999999999999997
91–100 of 107 posts
Re: 999999999999999 - 999999999999997
#92Earlier quoted context omitted.
It's a combination of ignorance and desensitization. My generation grew up with tubgirl and 2girls1cup. I first saw tubgirl/lemon party when I was 13. When I was I think 17, I came across goatse for the first time; by then, a man * his wide wasn't enough to faze me. I wrote an essay about how this widespread desensitization will affect society and culture. It'll be interesting to see the world in twenty years.
After browsing around your site for a few minutes, I didn't find this essay. Link?
I have to remember to shut that site down. I removed almost all my stuff back in June. It's all archived, but the archives aren't online yet. I'm trying to figure out how best to put it all up again.
My new essays are all on Facebook at the moment.
Re: 999999999999999 - 999999999999997
#93IEEE 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.
Re: 999999999999999 - 999999999999997
#94Both 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...
Re: 999999999999999 - 999999999999997
#95Earlier 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..
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?
Re: 999999999999999 - 999999999999997
#96Earlier 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.
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 oth…
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.
Re: 999999999999999 - 999999999999997
#97Earlier quoted context omitted.
I like Lisp too, but there's nothing especially accurate about it's arithmetic that you can't get in other civilized languages.
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 r…
These days quite a few languages already support bignums, rationals and even complex numbers. CL's support for these was unique back then, but I guess it has lost its edge in this domain.
Still, support of strict read/write invariance of floating point numbers (e.g. as described in Burger&Dybvig 1996 and Clinger 1990) doesn't seem to spread widely outside CL/Scheme camp. Concept of exact/inexact numbers as well.
Re: 999999999999999 - 999999999999997
#98Re: 999999999999999 - 999999999999997
#99Earlier quoted context omitted.
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.
One of my favorite pranks on Squeak was to do "true := false" in a workspace window.
Sadly, it no longer works...
Re: 999999999999999 - 999999999999997
#100Here 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.