Numpys, 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. Paul P.S. I still am looking for help on solving the Numeric bug on Alphas. -----Original Message----- From: numpy-developers-admin@lists.sourceforge.net [mailto:numpy-developers-admin@lists.sourceforge.net]On Behalf Of Travis Oliphant Sent: Monday, July 23, 2001 12:46 PM To: numpy-developers@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 specific). Many, including me, prefer returning an array with some undefined entries rather than raising an error and ruining the rest of the perfectly valid computations. Proposed solutions: 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 solution. Please let me know your position on this, so we can take action if warranted. Sincerely, Travis Oliphant _______________________________________________ Numpy-developers mailing list Numpy-developers@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/numpy-developers