[Numpy-discussion] Deprecate np.max/np.min ?
Fri Nov 6 13:01:02 CST 2009
On Fri, Nov 6, 2009 at 1:22 PM, Pauli Virtanen <email@example.com> wrote:
> pe, 2009-11-06 kello 12:57 -0500, firstname.lastname@example.org kirjoitti:
>> It follows the same pattern for missing brackets as many of the other
>> functions, where I often have typos.
>> >>> np.min(3,2)
>> >>> np.sum(3,2)
>> >>> np.ones(3,2)
> I think you are thinking about Matlab now...
I'm using (almost) as much matlab as python, so some confusion and
typos show up very regularly.
> The issue here is that Numpy's `min` and `max`, if used like their
> Python counterparts, give surprising results. `sum`, `ones`, `round`,
> etc. don't have this problem. The prepended `a` in the beginning is IMO
> not a big price to pay for reduced overloading.
> OTOH, one can ask, why is
> np.min(3, 2)
> allowed when
> np.min(, 2)
> gives "ValueError: axis(=2) out of bounds". It seems to me that
> 0-dimensional objects should accept only None as the axis? (Fixing this
> would also make misuse of np.min and np.max more difficult.)
That was also my first reaction, I think this axis check would be a
good improvement. I wanted to say we could improve the documentation
for numpy.min and add a warning, but I don't find the function min in
the docs (only amin and the method)
In general, I think shadowing python's built-in functions is a bad
idea and the missing namespaces make some code difficult to read and
makes it difficult to find problems.
I could always do import numpy.amin as npmin
which would be only a change by one dot.
But still breaking a lot of code, just for some cosmetic changes ?
What about np.ma.min, np.recarray.min (raises exception)? (matrix.min
is only available as method)
> Pauli Virtanen
> NumPy-Discussion mailing list
More information about the NumPy-Discussion