On Aug 12, 2008, at 9:54 AM, Anne Archibald wrote: > Er, is this actually a bug? I would instead consider the fact that > np.min([]) raises an exception a bug of sorts - the identity of min is > inf.
That'll break consistency with the normal 'max' function in Python. > Really nanmin of an array containing only nans should be the same > as an empty array; both should be infinity. One thing I expect is that if min(x) exists then there is some i where x[i] "is" min(x) . Returning +inf for min([NaN]) breaks that. However, my expectation doesn't hold true for Python. If I use Python's object identity test 'is' then object identity is lost in numpy.min, although it is preserved under Python's min: >>> import numpy as np >>> x = [200, 300] >>> np.min(x) 200 >>> np.min(x) is x[0] False >>> min(x) is x[0] True >>> and if I use '==' for equality testing then my expectation will fail if isnan(x[i]) because then x[i] != x[i]. >>> import numpy as np >>> np.nan nan >>> np.nan == np.nan False So when I say "is" I means "acts the same as except for in some strange corner cases". Or to put it another way, it should be possible to implement a hypothetical 'argnanmin' just like there is an 'argmin' which complements 'min'. > I guess this is a problem for types that don't have an infinity > (returning maxint is a poor substitute), but what is the correct > behaviour here? "Doctor, doctor it hurts when I do this." "Well, don't do that." Raise an exception. Refuse the temptation to guess. Force the user to handle this case as appropriate. Personally, I expect that if my array 'x' has a NaN then min(x) must be a NaN. Andrew [EMAIL PROTECTED] _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion