[SciPy-dev] problems with amin/amax when nan present

Pearu Peterson pearu at cens.ioc.ee
Fri Aug 16 10:50:14 CDT 2002


On Fri, 16 Aug 2002, eric wrote:

> So, I've found an ugly fix listed at the end of this message.  It will
> make amin/amax slower (probably 2X) even for the case when NaNs aren't
> present because it has to test for if any NaNs exists.  Correct is more
> important than fast, but I was wondering if anyone has a better
> solution.  We could test within the minimum/maximum methods in C using
> isnan(), I suppose, to save the extra array creation.

Does it makes sense to fix this in Numeric? I am not sure if Numeric is
supposed to support NaNs but considering that soon (?) Numeric will be
unmaintained (see Numarray's design) and (I guess) it would be rather
difficult to make the transformation from Numeric to Numarray quickly, then
we could start taking over Numeric array stuff by fixing this kind of
issues. It sounds radical (which I don't like) and I really hope that
starting to use Numarray in SciPy would be easier (for me it would mean
implementing Numarray support for f2py and here I have no idea how
difficult it turns out to be).

On the other hand, amax and amin are probably not heavily used in large
scale calculations so that the above would be no worth of trouble.
May be amin/amax should have an extra flag for disabling isnan checking?

Just some random thoughts ...
	Pearu




More information about the Scipy-dev mailing list