[Numpy-discussion] RE: [Numpy-developers] Error behavior.
Paul F. Dubois
paul at pfdubois.com
Tue Jul 31 10:22:53 CDT 2001
This is Travis' original message to the developers list, discussing his
ideas for dealing with floating point errors. When I answered him a minute
ago I inadvertently posted to this list instead. But, it is a good idea to
have everyone's thoughts. I only ask that you keep the noise down and not
have this degenerate into the numerous IEEE discussions we have had before.
P.S. I still am looking for help on solving the Numeric bug on Alphas.
From: numpy-developers-admin at lists.sourceforge.net
[mailto:numpy-developers-admin at lists.sourceforge.net]On Behalf Of Travis
Sent: Monday, July 23, 2001 12:46 PM
To: numpy-developers at lists.sourceforge.net
Subject: [Numpy-developers] Error behavior.
Many have noticed that with one of the newer Python releases, domain and
range errors on one of the computations in an element-by-element umath
function now always raise Python errors.
It used to be that one could say:
>>> x = arange(1,10)
>>> y = arange(0,9)
>>> print x/y
and get an output with reasonable values in positions 1..9 of the output
array but get an inf in the first position (how inf printed was platform
Many, including me, prefer returning an array with some undefined entries
rather than raising an error and ruining the rest of the perfectly valid
1) Make a new module (bring back the old fastumathmodule), which does not
set the "check" flag when the ufunc is created so that error are not
raised --- quick and fast fix.
2) Use the warnings framework so that rather than raise a Python error, a
warning is issued. This allows the user to do what they want with the
warning (from raise an error to ignore it). --- this feels like a better
Please let me know your position on this, so we can take action if
Numpy-developers mailing list
Numpy-developers at lists.sourceforge.net
More information about the Numpy-discussion