[no subject]

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

I still haven't seen a convincing argument for why disallowing
mixed-type complexes is needed for efficiency reasons.
Given the generic arithmetic operators on non-complex numbers this
restriction of form only makes my implementations more complicated
and slower. I humbly submit that machines with complex-floating-point
datatypes built-in can uses those instructions, and complicate
their implementation, since it is worth it, and they can do it
*without* requiring universal restrictions. It is a fairly
standard sort of optimization.

How about somebody giving a good argument here rather than a
"I'm told that, but I really don't have the ... to know."

It is somewhat puzzling that we have this uniformity rule embraced,
at the same time we have #C(3 0) => 3, a rule which surely breaks
some *easy* data-uniformity optimizations, although it certainly doesn't
require that #C(3 0) always be stored as 3, only that it never escapes
to the user as #C(3 0). Get my drift? 

On the subject of (SQRT -1.0), let us consider Macsyma, a program
much used, even for floating point calculations. It never seemed
to bother people that Macsyma had rational and complex numbers
(of a sort), since sometimes it made for serendipity -- but
errors are eventually caught -- and presumably it will be easier
to DEBUG a program in common-lisp than in fortran, so the more
powerful operators in CL can be forgiven. In any case the
Macsyma *compiler* I wrote had two things, a switch
TR_FLOAT_CAN_BRANCH_COMPLEX, somewhat of a kludge, and a form
MODE_IDENTITY, like common-lisp's "THE."
So people could write MODE_IDENTITY(FLOAT,SQRT(X)).
They didn't mind the greater verbosity because they had Emacs...

My attitude is that these features, such as "/" returning a rational,
*cost* a certain amount, in changing code, and runtime perhaps, so
that once we (our users) pay this price we (our users) aught to get
the greatest flexibility for it.

So here we have a rule about uniformity of complex numbers. What does
it cost?
(1) More documentation to read.
(2) More runtime checking when making complex numbers.
(3) Reduction in possible objects to manipulate.

What are the universal benefits? (Non-universal ones should be
gotten by restrictive declarations in my book.)