proposal: min, max of complex should give warning
![](https://secure.gravatar.com/avatar/0b7d465c9e16b93623fd6926775b91eb.jpg?s=120&d=mm&r=g)
I propose the following change: min, max applied to complex should give a warning. The rationale is, when the user applies min or max to complex, it's probably a mistake.
![](https://secure.gravatar.com/avatar/2ed170f366fc7841334af33ece2f9914.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/0b7d465c9e16b93623fd6926775b91eb.jpg?s=120&d=mm&r=g)
Cera, Tim wrote:
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.
![](https://secure.gravatar.com/avatar/5f88830d19f9c83e2ddfd913496c5025.jpg?s=120&d=mm&r=g)
On Tue, Dec 31, 2013 at 4:52 PM, Neal Becker <ndbecker2@gmail.com> wrote:
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
![](https://secure.gravatar.com/avatar/5f88830d19f9c83e2ddfd913496c5025.jpg?s=120&d=mm&r=g)
On Tue, Dec 31, 2013 at 5:45 PM, Neal Becker <ndbecker2@gmail.com> wrote:
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
![](https://secure.gravatar.com/avatar/2ed170f366fc7841334af33ece2f9914.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/0b7d465c9e16b93623fd6926775b91eb.jpg?s=120&d=mm&r=g)
Cera, Tim wrote:
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.
![](https://secure.gravatar.com/avatar/5f88830d19f9c83e2ddfd913496c5025.jpg?s=120&d=mm&r=g)
On Tue, Dec 31, 2013 at 4:52 PM, Neal Becker <ndbecker2@gmail.com> wrote:
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
![](https://secure.gravatar.com/avatar/5f88830d19f9c83e2ddfd913496c5025.jpg?s=120&d=mm&r=g)
On Tue, Dec 31, 2013 at 5:45 PM, Neal Becker <ndbecker2@gmail.com> wrote:
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
participants (3)
-
Cera, Tim
-
Neal Becker
-
Ralf Gommers