[SciPy-user] numarray complex comparisons

[Prabhu Ramachandran]

Hi,

>>>>> "EJ" == eric jones <eric at enthought.com> writes:

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

Well, I'm pretty bothered by this decision.  Here are a few things to
think about.

 1. Defining an order for complex numbers is ambiguous.  There is no
 way you can do it right.  Pick one and something else breaks.  So why
 pick anything?  Generating an exception seems the "right" thing to
 do.  I think doing it right is more important than more features or
 whatever.  Compromises tend to make you pay heavily later.

 2. Numeric does a lot of nice things magically (broadcasting etc.)
 and it works because Numeric defined it that way and people are used
 to it.  Treating complex numbers the same way as treating arrays is
 not right.  Complex numbers came first and people are trained to
 think in certain ways about them.  So doing something that would go
 against what is known (or commonly believed) is not the right
 direction to take.

 3. IIRC the problem Eric had was that the users thought the data was
 real, which it really was but for some small imaginary noise.  To me
 it seems that adding an order to complex numbers is the wrong kind of
 fix.  If the user thought the result of some procedure was supposed
 to be real and it is not then the user has a problem and must deal
 with it.  Why should the library try to imagine the right thing to do
 by itself?  Especially when something is potentially wrong and could
 later lead to funny problems.

 4. Most Python developers seem to like the philosphy "explicit is
 better than implicit".  This has worked very well for them.  Why go
 againt it?

 5. Even if you do decide to go ahead and define comparisons between
 complex numbers it would lead to nasty situations.

  Lets say you define '<' and '>' such that it applies to the real
  part of the number.  Then how do you define equality?  If you define
  it as requiring both the real and imaginary to be equal then you
  have an inconsistent order relation.  You can find many numbers that
  are "equal" and yet not identical.  If you use |z| as the
  determining parameter then again you are in for trouble.

So, I think that you should simply raise an exception if you expected
a real number and got a complex number instead.  If this is way too
painful to have to deal with then make some assumption and print it
clearly each time you make that assumption so that the user knows
exactly what is going on and where.  I think this is the cleanest
solution that I'll be confortable with.  Anything else makes me
uncomfortable.  Maybe its because I am not used to this, I dont know.

Thanks for listening.

cheers,
prabhu

p.s. shouldnt this discussion be on scipy-dev?