John Hunter wrote:
> My 2 cents is that I think Fernando is right on this
> issue. I'd rather go with a solution that causes temporary
> pain for matlab users rather than one that causes
> lingering, long-term irritations.
OK, looks like a consensus to me 
I guess my opinion on this is already clear :).
I'm happy with Fernando's proposed names amin, amax, around, etc. If
everyone else is too, I propose Andrew implement his patch, provide
the compatibility names, and update the relevant docs to advertise
this prominently: API_CHANGES, CHANGELOG, tutorial and users guide.
Particularly in the latter two, I think we should warn people about
the potential performance hit of using the builtin min, max and
friends on large arrays.
I'm happy to implement whatever the consensus is, but I'm quite busy this week and away this weekend, so it'll be next week until I can do anything. If someone else wants to jump in and do it, I certainly won't mind.
Norbert Nemec wrote:
There might be a solution that avoids the performance hit: there should not be any problem with pylab offering an optimized set of min, max, etc. as long as their signature is identical to the builtins and the behavior only extends them. Something along the line of:
def min(*args, **kwargs):
if args == ():
raise TypeError, "min() takes at least 1 argument (0 given)"
if len(args) == 1 and type(args[0]) is ArrayType:
axis=kwargs.pop('axis',0)
res = minimum.reduce(args[0],axis)
else:
res = __builtin__.min(*args)
if len(kwargs)>0:
raise TypeError, (
"min() got an unexpected keyword argument '%s'"
%kwargs.keys()[0]
)
return res
What do people think about Norbert's "best of both worlds" approach? Although it seems great in theory, I'm disinclined to use it simply because it does override the builtin. Although he's doubtlessly constructed this with the greatest of care to perform exactly as the builtin, I wonder about obscure corner cases which won't behave exactly the same and may result in even more obscure bugs. Maybe my misgivings are undue paranoia on my part, and his 3rd way really is best. I suppose I'd want to throw lots of tests at it before I pronounce my final judgement on it, which I don't have time to do at the moment. (Next week, if need be...)
Just a thought for consideration: perhaps Norbert's code could actually be used by the underlying mlab.py modules? I guess some code in the wild uses the axis argument not as a keyword, so there would be a backwards incompatible change in that regard... Other than that, though, this kind of behavior from the mlab.py modules would probably have resulted in a less serious conundrum than what we now face.
Also, we must not forget about round, sum, and abs (and any others I have missed). For example, abs() caught me because I use the cgkit quaternion type, which overrides the __abs__ method and thus fails to work properly with the mlab.py implementation of abs().
Cheers!
Andrew