[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: Common-Lisp @ SU-AI*From*: George J. Carrette <GJC @ MIT-MC>*Date*: Tue, 07 Jun 1983 06:03:00 -0000

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.)

- Prev by Date:
**NTH-VALUE** - Next by Date:
**[Re: revenge of the ballot, B7]** - Previous by thread:
**Multiple-value-revenge of the Ballot** - Next by thread:
**[Re: revenge of the ballot, B7]** - Index(es):