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

[Ralf Gommers]

On Tue, Dec 31, 2013 at 5:45 PM, Neal Becker <ndbecker2 at gmail.com> wrote:

> 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.
>

That I had guessed. I meant: can you try to add this warning and then see
if it catches any bugs or displays any incorrect warnings for scipy and
some scikits?

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20140104/69e98ba1/attachment.html>