x.min() depends on ordering

Tim Hochberg tim.hochberg at ieee.org
Sat Nov 11 19:55:21 CST 2006


Charles R Harris wrote:
>
>
> On 11/11/06, *Tim Hochberg* <tim.hochberg at ieee.org 
> <mailto:tim.hochberg at ieee.org>> wrote:
>
>     Robert Kern wrote:
>     > Keith Goodman wrote:
>     >
>     >> How about a nanmin() function?
>     >>
>     >
>     > Already there.
>     >
>     > In [2]: nanmin?
>     > Type:           function
>     > Base Class:     <type 'function'>
>     > Namespace:      Interactive
>     > File:
>     >
>     /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy-1.0.1.dev3432-py2.5-macosx-10.4-i386.egg/numpy/lib/function_base.py
>     > Definition:     nanmin(a, axis=None)
>     > Docstring:
>     >     Find the minimium over the given axis, ignoring NaNs.
>     >
>     >
>     Bah! That seems excessive. If I was king of the world one of the many
>     things that I would stuff into a submodule is all the stuff
>     relating to
>     special values (nan, inf, isnan, isinf, namin, nanmax, nansum,
>     nanargmax, nanargmin, nan_to_num, infty,  isneginf, isposinf and
>     probably some others that I'm missing). First, these are mostly
>     clutter
>     in the base namespace. Not only would it make the main namespace
>     easier
>     to navigate in (although there's much clean up that would have to be
>     done before it would be anything approaching easy to navigate).
>     Second,
>     for those who actually do need them, they'd be easier to find if they
>     were all grouped together -- Keith for example would almost certainly
>     have immediately found nanmin. Third, and this is perhaps a matter of
>     opinion, there seems to be a sudden urge to abuse NaNs. Perhaps if
>     they
>     were shunted a bit off to the side, this temptation would be lifted.
>
>     Curmudgeonly yours,
>
>
> Oh yes. And let's reserve a bit of abuse for whoever mixed up the nans 
> with the rest. I mean, the infs and such actually make some sense as 
> numbers, but nans are, well, nans. So it would have been nice to 
> enable everything *except* nans, and have an errorflag set whenever 
> the latter turned up.
Actually you can do this. At least for the most part, I'm sure there are 
some corners that aren't working right yet.  Operations on NaNs set the 
invalid flag while infinities set the overflow flag (actually the flags 
are only set when you first get the infinity or NaN, at least on my 
platform). So, you can make invalid a flag and ignore overflow by using:

np.seterr(over='ignore', invalid='raise')

I doubt this does *exactly* what you want, but it may be close.

-tim


[snip]




-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642




More information about the Numpy-discussion mailing list