On Fri, 2006-08-04 at 09:06 +0100, Gary S. Thompson wrote:
there is an alternative 3 which would be to back port the
functionality
from numpy in the expectation that 'one of these days' numeric will
be
replaced by numpy (is numeric still maintained?)
also it would be possible to check whether nans etc produce the
expected
result at the start of the script and warn the user if they had a
non
compliant result.
A final note is that i believe scipy propogates nan infs etc properly
whereas numeric doen't for ufuncs and some other cases...
http://cens.ioc.ee/~pearu/scipy/tutorial.pdf
As I understand, Numeric is no longer maintained, and Numpy is its
appointed successor, so in that sense porting to Numpy will be
neccessary some time soon anyway. In principle it should be a fairly
trivial process - changing the import statements being the major job.
The thing that makes things more complicated, however, is that
Scientific is still reliant on Numeric and not 'yet' compatible with
Numpy. So if we do move over to Numpy, an alternative PDB parser will be
required (and another MPI interface?).
The issue with Numeric's handling of NaN and INFs is that often it will
raise a FloatingPointError of one flavour or another, rather than
returning NaN or INF. Divide by zero is the clasic example, but there
are many others. This is also true of Python's math functions, and again
is fairly platform dependent. The propagation of NaNs is OK though, i
think. That is, NaN is always the result of any math operation on NaN.
Chris
Re: [bug #6503] Uncaught nan in xh_vect