On Tue, Dec 31, 2013 at 4:52 PM, Neal Becker <ndbecker2@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