proposal: min, max of complex should give warning
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.
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/Rmanual/Rpatched/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
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/Rmanual/Rpatched/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.
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/Rmanual/Rpatched/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
Ralf Gommers wrote:
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/Rmanual/Rpatched/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.
On Tue, Dec 31, 2013 at 5:45 PM, Neal Becker ndbecker2@gmail.com wrote:
Ralf Gommers wrote:
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/Rmanual/Rpatched/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
participants (3)

Cera, Tim

Neal Becker

Ralf Gommers