Complex Arguments, fear and loathing on the number line.

[George J. Carrette <GJC @ MIT-ML>]

My feeling is that adding simplification rules on the results of
a function are ok as long as it doesn't get out of hand. One might
write this:

(defmethod ((complex complex) :plus) (x y)
  (make-complex (+ (send x :real) (send y :real))
		(+ (send x :imag) (send x :imag))))

And if make-complex is a routine which checks for the simplification
case I don't mind, although I would mind if this sets a precedent
for more simplification rules. It could simply get very complex
and slow down the implementations enough so that potential users
would go back to their own devices such as MAKE-COMPLEX = CONS.

That is why I would shy away from making any claims about disallowing
certain forms of numbers. I find nothing wrong with #C(3.3 5)
or #C(0.3 3/4), although it might not be easy to generate such
a thing besides having typed it in. (e.g.
(+ 3.3 #C(0 3/4)) is sure to produce #C(3.3 0.75) naturally, by
3.3 => #C(3.0 0.0) ; extend to complex by getting the ZERO of the type of 3.3)
The same argument goes for various forms of non-uniform floating-point
combinations. Even if somebody does type one in I don't see how a
good implementation of the arithmetic would care.

Maybe this is another good time to quote from the "Federalist Papers"
about how it isn't a good idea to make a law against something that
you can't fathom happening anyway.