[Python-Dev] Not-a-Number (was PyObject_RichCompareBool identity shortcut)
ncoghlan at gmail.com
Sun May 1 13:27:44 CEST 2011
On Sat, Apr 30, 2011 at 3:11 AM, Guido van Rossum <guido at python.org> wrote:
> Decimal, for that reason, has a context that lets one specify
> different behaviors when a NaN is produced. Would it make sense to add
> a float context that also lets one specify what should happen? That
> could include returning Inf for 1.0/0.0 (for experts), or raising
> exceptions when NaNs are produced (for the numerically naive like
> I could see a downside too, e.g. the correctness of code that
> passingly uses floats might be affected by the context settings.
> There's also the question of whether the float context should affect
> int operations; floats vs. ints is another can of worms since (in
> Python 3) we attempt to tie them together through 1/2 == 0.5, but ints
> have a much larger range than floats.
Given that we delegate most float() behaviour to the underlying CPU
and C libraries (and then the math module tries to cope with any
cross-platform discrepancies), introducing context handling isn't
easy, and would likely harm the current speed advantage that floats
hold over the decimal module.
We decided that losing the speed advantage of native integers was
worthwhile in order to better unify the semantics of int and long for
Py3k, but both the speed differential and the semantic gap between
float() and decimal.Decimal() are significantly larger.
However, I did find Terry's suggestion of using the warnings module to
report some of the floating point corner cases that currently silently
produce unexpected results to be an interesting one. If those
operations issued a FloatWarning, then users could either silence them
or turn them into errors as desired.
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-Dev