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/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
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.
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
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/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.
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/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
participants (3)
-
Cera, Tim -
Neal Becker -
Ralf Gommers