math.nroot [was Re: A brief question.]

[Michael Hudson]

Tim Peters <tim.peters at gmail.com> writes:

> All Python behavior in the presence of infinities, NaNs, and signed
> zeroes is a platform-dependent accident, mostly inherited from that
> all C89 behavior in the presence of infinities, NaNs, and signed
> zeroes is a platform-dependent crapshoot.

As you may have noticed by now, I'd kind of like to stop you saying
this :) -- at least on platforms where doubles are good old-fashioned
754 8-byte values.

But first, I'm going to whinge a bit, and lay out some stuff that Tim
at least already knows (and maybe get some stuff wrong, we'll see).

Floating point standards lay out a number of "conditions": Overflow
(number too large in magnitude to represent), Underflow (non-zero
number to small in magnitude to represent), Subnormal (non-zero number
to small in magnitude to represent in a normalized way), ...

For each condition, it should (at some level) is possible to trap each
condition, or continue in some standard-mandated way (e.g. return 0
for Underflow).

While ignoring the issue of allowing the user to control this, I do
wish sometimes that Python would make up it's mind about what it does
for each condition.  There are a bunch of conditions which we
shouldn't and don't trap by default -- Underflow for example.  For the
conditions that probably should result in an exception, there are
inconsistencies galore:

>>> inf = 1e300 * 1e300 # <- Overflow, no exception
>>> nan = inf/inf # <- InvalidOperation, no exception
>>> pow(1e100, 100) <- Overflow, exception
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: (34, 'Numerical result out of range')
>>> math.sqrt(-1) # <- InvalidOperation, exception
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: math domain error

At least we're fairly consistent on DivisionByZero...

If we're going to trap Overflow consistently, we really need a way of
getting the special values reliably -- which is what pep 754 is about,
and its implementation may actually work more reliably in 2.5 since my
recent work...

On the issue of platforms that start up processes with traps enabled,
I think the correct solution is to find the incantation to turn them
off again and use that in Py_Initialize(), though that might upset
embedders.

Cheers,
mwh

-- 
  <Yosomono> rasterman is the millionth monkey
                                                -- from Twisted.Quotes