The questions just keep coming... We need to decide whether or not complex comparisons work. They do not work for Python scalars. Consistency would argue for them not working for numarray arrays. However some argue: 1) not allowing them defeats more generic programming. We agreed until we found that IDL doesn't support them either, and we never noticed. We are skeptical of this claim and would like to see real-life examples. 2) it is useful to allow comparisons since that would result in repeatable, sorting of values (e.g., to find duplicate values) for ordering purposes. Cannot this just be handled by the sort routines themselves? Why must this result in comparison operators working? In the absence of good examples for 1) or good arguments for 2) we propose to make complex comparisons generate exceptions. Perry Greenfield
The questions just keep coming...
We need to decide whether or not complex comparisons work. They do not work for Python scalars. Consistency would argue for them not working for numarray arrays. However some argue:
1) not allowing them defeats more generic programming. We agreed until we found that IDL doesn't support them either, and we never noticed. We are skeptical of this claim and would like to see real-life examples.
2) it is useful to allow comparisons since that would result in repeatable, sorting of values (e.g., to find duplicate values) for ordering purposes. Cannot this just be handled by the sort routines themselves? Why must this result in comparison operators working?
In the absence of good examples for 1) or good arguments for 2) we propose to make complex comparisons generate exceptions.
What is the argument against allowing __eq__ to continue to work, while disallowing __lt__ and friends. The former is well defined. I know comparing floating point number for equality is a bit of a suckers game, but were allowing it for floats and it's sometimes useful. On second thought, maybe I'm just misinterpreting you here since __eq__ works fine for complex scalars. -tim
Tim Hochberg write:
What is the argument against allowing __eq__ to continue to work, while disallowing __lt__ and friends. The former is well defined. I know comparing floating point number for equality is a bit of a suckers game, but were allowing it for floats and it's sometimes useful.
On second thought, maybe I'm just misinterpreting you here since __eq__ works fine for complex scalars.
-tim
I wasn't clear on this. What I was arguing was that less, less_equal, greater, greater_equal would not work, but that equal and not_equal Primarily because that is what Python does. It does allow one to test for equality (or non equality), but doesn't allow for >,<,>=,<=, which is sensible in my view. Perry
participants (2)
-
Perry Greenfield -
Tim Hochberg