From: Charles R H. <cha...@gm...> - 2006-11-12 01:06:59
|
On 11/11/06, Tim Hochberg <tim...@ie...> 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. Or if folks just have to have nans, make them compare less than anything else. If isnan were fast and easy one could use LT(a,b) := isnan(a) || a < b. Chuck |