Re: [Numpy-discussion] Unfortunate user experience with max()
Johannes Loehnert wrote: >>numpy.sum(x, axis=None, dtype=None, out=None) >>vs. >>sum(sequence, start=0) >> >> The problem here is that Numeric had sum before Python had sum. So, there is a legacy issue. As you can tell, there are limits to my concern of shadowing builtins. That's what name-spaces are for :-) But, I'm sympathetic to bite-wounds. -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Unfortunate user experience with max()
Hi, > > This can lead to surprising bugs in code that either explicitly > > expects it to behave like python's max() or implicitly expects that by > > doing "from numpy import max". my solution is to never use numpy.max. For arrays, I always use the method call (somearray.max()). For everything else the builtin. > I don't think we can reasonably change that in a 1.0 release, but I'm > all in favour of removing numpy.max in 1.1. Shadowing builtins is a > bad idea. The same goes for numpy.sum, which, at the least, should be > modified so that the function signatures are compatible: > numpy.sum(x, axis=None, dtype=None, out=None) > vs. > sum(sequence, start=0) +1 from me. Real world example where the shadowing made my code not work: >>> l = [[1, 2], [5, 6, 7], [9]] >>> l2 = sum(l, []) builtin result: l2 == [1, 2, 5, 6, 7, 9] numpy.sum result: exception... My suggestion for this would be to remove all shadowing in favor of array methods. Though I am aware this would break *lots* of "legacy" code. cu, Johannes ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Unfortunate user experience with max()
On 5/17/07, David M. Cooke <[EMAIL PROTECTED]> wrote: On Wed, May 16, 2007 at 09:03:43PM -0400, Anne Archibald wrote: > Hi, > > Numpy has a max() function. It takes an array, and possibly some extra > arguments (axis and default). Unfortunately, this means that > > >>> numpy.max(-1.3,2,7) > -1.3 > > This can lead to surprising bugs in code that either explicitly > expects it to behave like python's max() or implicitly expects that by > doing "from numpy import max". > > I don't have a *suggestion*, exactly, for how to deal with this; > checking the type of the axis argument, or even its value, when the > first argument is a scalar, will still let some bugs slip through > (e.g., max(-1,0)). But I've been bitten by this a few times even once > I noticed it. > > Is there anything reasonable to do about this, beyond conditioning > oneself to use amax? 1) Don't do 'from numpy import max' :-) 2) 'from numpy import *' doesn't import max, so that's ok I don't think we can reasonably change that in a 1.0 release, but I'm all in favour of removing numpy.max in 1.1. Shadowing builtins is a bad idea. The same goes for numpy.sum, which, at the least, should be modified so that the function signatures are compatible: numpy.sum(x, axis=None, dtype=None, out=None) vs. sum(sequence, start=0) For numpy.max at least, not accepting a fractional value as an axis would probably catch a large case of common errors. I mean it doesn't seem like it should be legal to say 'axis=2.7'. --bb ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Unfortunate user experience with max()
On 5/16/07, David M. Cooke <[EMAIL PROTECTED]> wrote: On Wed, May 16, 2007 at 09:03:43PM -0400, Anne Archibald wrote: > Hi, > > Numpy has a max() function. It takes an array, and possibly some extra > arguments (axis and default). Unfortunately, this means that > > >>> numpy.max(-1.3,2,7) > -1.3 > > This can lead to surprising bugs in code that either explicitly > expects it to behave like python's max() or implicitly expects that by > doing "from numpy import max". > > I don't have a *suggestion*, exactly, for how to deal with this; > checking the type of the axis argument, or even its value, when the > first argument is a scalar, will still let some bugs slip through > (e.g., max(-1,0)). But I've been bitten by this a few times even once > I noticed it. > > Is there anything reasonable to do about this, beyond conditioning > oneself to use amax? 1) Don't do 'from numpy import max' :-) 2) 'from numpy import *' doesn't import max, so that's ok I don't think we can reasonably change that in a 1.0 release, but I'm all in favour of removing numpy.max in 1.1. Shadowing builtins is a bad idea. PyChecker warns of a number of such shadowings in numpy. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Unfortunate user experience with max()
On Wed, May 16, 2007 at 09:03:43PM -0400, Anne Archibald wrote: > Hi, > > Numpy has a max() function. It takes an array, and possibly some extra > arguments (axis and default). Unfortunately, this means that > > >>> numpy.max(-1.3,2,7) > -1.3 > > This can lead to surprising bugs in code that either explicitly > expects it to behave like python's max() or implicitly expects that by > doing "from numpy import max". > > I don't have a *suggestion*, exactly, for how to deal with this; > checking the type of the axis argument, or even its value, when the > first argument is a scalar, will still let some bugs slip through > (e.g., max(-1,0)). But I've been bitten by this a few times even once > I noticed it. > > Is there anything reasonable to do about this, beyond conditioning > oneself to use amax? 1) Don't do 'from numpy import max' :-) 2) 'from numpy import *' doesn't import max, so that's ok I don't think we can reasonably change that in a 1.0 release, but I'm all in favour of removing numpy.max in 1.1. Shadowing builtins is a bad idea. The same goes for numpy.sum, which, at the least, should be modified so that the function signatures are compatible: numpy.sum(x, axis=None, dtype=None, out=None) vs. sum(sequence, start=0) -- |>|\/|< /--\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |[EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Unfortunate user experience with max()
Anne Archibald wrote: > On 16/05/07, Alan G Isaac <[EMAIL PROTECTED]> wrote: >> On Wed, 16 May 2007, Anne Archibald apparently wrote: >> numpy.max(-1.3,2,7) ^ typo >>> -1.3 >> Is that new behavior? >> I get a TypeError on the last argument. >> (As expected.) > For which version of numpy? > > In [2]: numpy.max(-1.3,2.7) > Out[2]: -1.3 Ah, you had a typo in your original message, conveniently labeled above. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Unfortunate user experience with max()
On 16/05/07, Alan G Isaac <[EMAIL PROTECTED]> wrote: > On Wed, 16 May 2007, Anne Archibald apparently wrote: > numpy.max(-1.3,2,7) > > -1.3 > > Is that new behavior? > I get a TypeError on the last argument. > (As expected.) For which version of numpy? In [2]: numpy.max(-1.3,2.7) Out[2]: -1.3 In [3]: numpy.__version__ Out[3]: '1.0.1' Anne ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Unfortunate user experience with max()
On 5/16/07, Anne Archibald <[EMAIL PROTECTED]> wrote: > Numpy has a max() function. It takes an array, and possibly some extra > arguments (axis and default). Unfortunately, this means that > > >>> numpy.max(-1.3,2,7) > -1.3 > > This can lead to surprising bugs in code that either explicitly > expects it to behave like python's max() or implicitly expects that by > doing "from numpy import max". I have several bite marks from >> x matrix([[ 2.], [nan], [ 1.]]) >> numpy.max(x) 1.0 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Unfortunate user experience with max()
On Wed, 16 May 2007, Anne Archibald apparently wrote: numpy.max(-1.3,2,7) > -1.3 Is that new behavior? I get a TypeError on the last argument. (As expected.) Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Unfortunate user experience with max()
On 5/17/07, Anne Archibald <[EMAIL PROTECTED]> wrote: Hi, Numpy has a max() function. It takes an array, and possibly some extra arguments (axis and default). Unfortunately, this means that >>> numpy.max(-1.3,2,7) -1.3 This can lead to surprising bugs in code that either explicitly expects it to behave like python's max() or implicitly expects that by doing "from numpy import max". I don't have a *suggestion*, exactly, for how to deal with this; checking the type of the axis argument, or even its value, when the first argument is a scalar, will still let some bugs slip through (e.g., max(-1,0)). But I've been bitten by this a few times even once I noticed it. Is there anything reasonable to do about this, beyond conditioning oneself to use amax? I don't know what a good fix is, but I got bitten by that one the other day too. --bb ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Unfortunate user experience with max()
Hi, Numpy has a max() function. It takes an array, and possibly some extra arguments (axis and default). Unfortunately, this means that >>> numpy.max(-1.3,2,7) -1.3 This can lead to surprising bugs in code that either explicitly expects it to behave like python's max() or implicitly expects that by doing "from numpy import max". I don't have a *suggestion*, exactly, for how to deal with this; checking the type of the axis argument, or even its value, when the first argument is a scalar, will still let some bugs slip through (e.g., max(-1,0)). But I've been bitten by this a few times even once I noticed it. Is there anything reasonable to do about this, beyond conditioning oneself to use amax? Thanks, Anne M. Archibald ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
