[SciPy-user] numarray complex comparisons

[Tim Hochberg]

[eric]
> > I haven't commented because there are a lot of other things going on,
> > and Perry already knows my opinion on the subject.  There are multiple
> > generic code examples where this has bitten me, and I think I've even
> > provided demos during these discussions.  The errors only popped up a
> > year after the code was used in production because an end user passed in
> > complex values.  It can be argued that not throwing an exception will
> > result in even worse errors.  I simply disagree based on my experience.
[travis]
> I concur with Eric.
>
> Let complex comparisons just assume the user meant the real part only
> rather than throwing an error.

Please don't. I'm ocassionally in the business of comparing complex numbers
and this is what I want only about half the time. The other half the time I
compare |z| not real(z). This just gives me and everyone in my shoes more
rope to shoot ourselves in the foot.

If you insist on making SciPy differ in this way, please make it easy to
turn off!

If this must happen, it seems that the "the best thing" is to "crush
your..." no ummm... the best thing would by for the function used to map
complex numbers to floats for comparisons be settable in Numarray. Then
numarray could continue to do it the right way for it (throw an exception)
while SciPy could easily plug in it's own comparison function. For instance.

numarray.set_complex_comp_map(lambda V : V.real) # Do it Travis's way
numarray.set_complex_comp_map(lambda V : abs(V)) # Do it my way (although
I'd never actually do this)
numarray.set_complex_comp_map(None) # Turn it off (the way it should be ;)

> > Off the top of my head, allowing complex comparison and the default
> > value for the 'axis' keyword will likely be different in SciPy.
>
> Not to sound like Eric's parrot (we do disagree on some things :-)), but I
> have to again agree.

How is the axis keyword going to differ?

-tim