The Trouble With Rounding Floats

lukfil writes "We all know of floating point numbers, so much so that we reach for them each time we write code that does math. But do we ever stop to think what goes on inside that floating point unit and whether we can really trust it?"

Comments

I am Intel of Borg

[www.sorehands.com]

I am Intel of Borg, you will be approximated.

There have been many examples, such as the original pentium bug. Of course, there was a bug in Windows Calc, it was 2.01 - 2.0 = 0 (If I remember correctly).

Re:Numbers and bases

[tawhaki]

Try representing 1/3 in any finite number of digits.

0.3. All you need is base 9 :)

Re:Not news.

[mcrbids]

Using a float to represent monetary amounts and expecting them to be free of rounding errors is as stupid as using integers to store zip codes and wondering where the leading zeros went from all the addresses in New England.

Hrrmm, well...

That would explain our lack of customer response in New England...

Re:science; business

[Jeremi]

But today, is it more practical (and simple) just to use a language like Ruby, that has arbitrary-precision integers, so you can just store everything in units of cents?

Hmm.... if you use integers of any given finite precision, aren't you still subjecting yourself to round-off error? (e.g. ((int)4)/((int)3) == 1!!) On the other hand, if you use a string-based infinite-precision datatype, what happens when you try to compute an non-terminating number (e.g. 1.0/3.0)? Perhaps your program crashes after trying to allocate an infinite amount of RAM to store the result? ;^)

Seems to me the only full solution to round-off error would be to store the results of certain math operations as strings indicating the underlying mathematical/algebraic expressions (e.g. 1.0/3.0 == "1/3"), a la Matlab... but then, I'm no expert, perhaps there is a better way.

Re:Decimal Arithmetic

[gstoddart]

Since these are computers, and they deal primarily with binary internally

Last I checked, they use binary internally exclusively, not primarily. ;-)

Unless things have changed and nobody told me. :-P

Cheers

Re:decNumber libary from IBM

[Anonymous Coward]

Why would you use a factoring algorithm when you could just use the Euclidean algorithm to find the GCD of (n/d), and then divide the numerator and denominator by them?

If I had a factoring algorithm which was "proportional to the terms themselves" - that is, O(n) - I'd want to show it off, too. Though I'd probably restrain my urge until after I'd broken into RSA-protected bank systems and become ludicrously wealthy.

(Actually, I guess the commonly-stated running times are in terms of the number of bits, which is (lg n). So O(n) would be O(exp(b)), which isn't even as good as the general number field sieve. I killed my overly geeky joke. Oh well.)

The Answer

[BSonline]

Actually, the answer is 42.

Good thing I use double instead of float....

[gatkinso]

...THAT should keep me safe from thems nasty float errors!