123.4+2=125.40000000000001

[Tim Peters]

[Peter Koppatz]
> On my calculator: 123.4+2 = 125.4 !?

[Kalle Svensson]
> In fact, this probably isn't true. It's just that your calculator rounds
> the answer before handing it to you, just like print. Maybe. I should
> probably change my name to Search Deja... :)

Actually, on Peter's calculator it probably is true:  almost all hand
calculators today lack floating-point hardware, and use integer hardware to
simulate *decimal* floating-point via software.  The REXX language also uses
decimal floating point.  On "real computers", that's also possible, but much
slower than using their hardware binary floating point.

> Also note that there has been a lot of discussion on this topic here, and
> that the behavior might change in a later version of python.

It would sure be nice to have an alternative.  In a deep sense, it's
basically futile:  the deadly surprises in computer real arithmetic derive
from using a fixed amount of storage for each real value.  That gets you
into approximations ("round off error"), overflow & underflow, whether the
underlying system is binary, decimal, fixed-width rational, log or log-log,
...  The advantage to decimal floating point is mostly that people are
*accustomed* to the simpler kinds of errors it makes, thanks to calculator
and pencil-&-paper experience.  For example, nobody thinks to complain about
10/3 = 3.3333333 on an 8-digit hand calculator, or the later 3.3333333 * 3 =
9.9999999.  But do a similar thing with binary floating point, and they
suddenly feel violated <0.9 wink>.

floating-point-is-a-harsh-lover-ly y'rs  - tim