[Numpy-discussion] proposal: min, max of complex should give warning

[Neal Becker]

Ralf Gommers wrote:

> On Tue, Dec 31, 2013 at 4:52 PM, Neal Becker <ndbecker2 at gmail.com> wrote:
> 
>> Cera, Tim wrote:
>>
>> > I don't work with complex numbers, but just sampling what others do:
>> >
>> >
>> > Python: no ordering, results in TypeError
>> >
>> > Matlab: sorts by magnitude
>> > http://www.mathworks.com/help/matlab/ref/sort.html
>> >
>> > R: sorts first by real, then by imaginary
>> > http://stat.ethz.ch/R-manual/R-patched/library/base/html/sort.html
>> >
>> > Numpy: sorts first by real, then by imaginary (the documentation link
>> > below calls this sort 'lexicographical' which I don't think is
>> > correct)
>> > http://docs.scipy.org/doc/numpy/reference/generated/numpy.sort.html
>> >
>> >
>> > I would think that the Matlab sort might be more useful, but easy
>> > enough by using the absolute value.
>> >
>> > I think what Numpy does is normal enough to not justify a warning, but
>> > leave this to others because as I pointed out in the beginning I don't
>> > work with complex numbers.
>> >
>> > Kindest regards,
>> > Tim
>>
>> But I'm not proposing to change numpy's result, which I'm sure would raise
>> many
>> objections.  I'm just asking to give a warning, because I think in most
>> cases
>> this is actually a mistake on the user's part.  Just like the warning
>> currently
>> given when complex data are truncated to real part.
>>
> 
> Keep in mind that warnings can be highly annoying. If you're a user who
> uses this functionality regularly (and you know what you're doing), then
> you're going to be very unhappy to have to wrap each function call in:
>     olderr = np.seterr(all='ignore')
>     max(...)
>     np.seterr(**olderr)
> or in:
>     with warnings.catch_warnings():
>         warnings.filterwarnings('ignore', ...)
>         max(...)
> 
> The actual behavior isn't documented now it looks like, so that should be
> done. In the Notes section of max/min probably.
> 
> As for your proposal, it would be good to know if adding a warning would
> actually catch any bugs. For the truncation warning it caught several in
> scipy and other libs IIRC.
> 
> Ralf

I tripped over it yesterday, which is what prompted my suggestion.