numpy-discussion

[Numpy-discussion] numarray complex comparisons

[Perry G. <pe...@st...>]

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

[Numpy-discussion] Re: [SciPy-user] numarray complex comparisons

[Tim H. <tim...@ie...>]

> 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

RE: [Numpy-discussion] Re: [SciPy-user] numarray complex comparisons

[Perry G. <pe...@st...>]

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