[Python-Dev] Expert floats

Tim Peters tim.one at comcast.net
Wed Mar 31 22:51:13 EST 2004


[Tim]
>> Binary fp loses in these common cases *just because* the true inputs
>> can't be represented, and the number printed at the end isn't even
>> the true result of approximately adding the approximated inputs.
>> Decimal easily avoids all of that.

[Andrew Koenig]
> Well, some of it.  It still doesn't avoid 1E50 + 1E-50 == 1E50, for
> example.

It's not common for newbies to use exponential notation, and neither is it
common "for most everyday applications of decimal arithmetic" (which I was
talking about, in part of the context that got snipped) to have inputs
spanning 100 orders of magnitude.

If you know that *your* app has inputs spanning 100 orders of magnitude, and
you care about every digit, then set Decimal precision to something
exceeding 100 digits, and your sample addition will be exact (and then 1E50
+ 1E-50 > 1E50, and exceeds the RHS by exactly 1E-50).  That's what the
"easily" in "easily avoids" means -- the ability to boost precision is very
powerful!

> ...
> Then how about giving a warning for every floating-point literal that
> cannot be exactly represented in binary?

Well, I'm sure that pissing off everyone all the time would be a significant
step backwards.

BTW, so long as Python relies on C libraries for float<->string conversion,
it also has no way to know which floating-point literals can't be exactly
represented anyway.




More information about the Python-Dev mailing list