A fresh look at comparisons

[Paul D Anderson]

Yigal Chripun Wrote:

> >
> > The problem is that complex numbers become UNORDERED when the
> > imaginary part (of either number) becomes non-zero. opCmp() has no way
> > to express that. Henning Hasemann did suggest making opCmp return an
> > enum, instead of an int, so that all four possible returns could be
> > indicated, but again, like you, he's solving one problem at a time.
> > The whole "fresh look" approach is to solve all of the problems in one
> > fell swoop. So, this particular problem would be solved in my scheme
> > with
> >
> >     class Complex
> >     {
> >         is(this < c, unordered)
> >         {
> >             if (this.im == 0 && c.im == 0)
> >             {
> >                 return this.re < c.re;
> >             }
> >             else return false;
> >         }
> >     }
> >   
> 
> the above is a non-issue IMO. personally I HATE error return codes/enums
> (that's a C idiom and does _not_ belong in a modern language like D). (a
> < b) is an error for unordered types just like  "hello" + 2 is an error.
> nothing should be returned is in such a case it doesn't matter if it's
> an int or an enum. This is an error and should be dealt as such - either
> throw an exception or don't define an opCmp for complex (I prefer the
> latter since as you said so yourself, Complex numbers are unordered).
> I've previously said that opCmp should not be in Object and should not
> be defined for all types. a better design IMO is to have an interface
> "Ordered" and maybe also "PartialyOrdered" too. also, in conjunction
> with my previous post, they could be defined as annotations instead just
> like "explicit".
> 

Slightly OT -- I realize the Complex class is being used as an example to prove a point and this is not a discussion on the mathematics of complex numbers. However --

There are instances when an unordered field (i.e. complex numbers) may be considered to be ordered when reduced to an underlying field (i.e. real numbers), but I don't think it's good practice to build that exception into the definition. In other words the Complex class should always return false on  comparison since it is always unordered.

If an exception is allowed for the case where the imaginary parts are zero, why not when the real parts are zero? 0+3i is clearly ordered with respect to 0+4i. In fact any time the real OR imaginary parts are equal the corresponding parts are ordered. This is nothing more than ordering points on any constant imaginary or constant real line in the complex plane. IMHO a better case could be made for ordering complex numbers by comparing their norms, with the obvious deficit that two complex numbers with the same order would not necessarily be equal.

I recognize that there may be applications where, for good reason, real and complex numbers are mixed and that comparison of real numbers with real parts of complex numbers is needed. But I don't think that complex numbers are a good example of a "sometimes ordered" system and I'm not sure that such a system exists. opCmp() for any unordered system should always return false.

Paul