It may or may not be a good idea to allow Lisp complexes as part of Maxima
expressions. I tend to think it is not, for many of the reasons Fateman and
I have mentioned so far in this thread. But note that the output, part, and
subst cases are actually quite straightforwardly handled by the existing
architecture, where format1 (called by subst, part, displa, etc.) does
conversions like ((mexpt) x -1) => ((mquotient) 1 x); it could equally well
transform #c(1 2) => ((mplus) 1 ((mtimes) 2 $%i)).
But even if they are allowed, this does *not* mean that we can translate
Maxima arithmetic directly into native arithmetic. In fact, we can't even
do that for integers and rationals.
For example, the Common Lisp
spec<http://www.lispworks.com/documentation/HyperSpec/Issues/iss071_w.htm>;
(if
I'm interpreting it correctly) says that the result of (expt 4 1/2) can be
*either* an integer or a float -- GCL in particular returns a float. That
isn't acceptable for Maxima, where it must remain an integer. Also, I don't
believe the CL spec requires that rational powers of integers be calculated
exactly; GCL for example is an ULP off for 8^(1/3).
The Common Lisp spec defines (expt 0 0) => 1 and (expt 0.0 0) => 1.0.
Whether we want that to become the Maxima default or not (I know many
people have argued for it), we probably want to preserve the *option* of
giving an error for it.
True, it is easier to *recognize* a complex if it's in the form #c(1 2) than
in the form 1+2*%i, but Maxima will always have to be able to manipulate the
latter (including cases where it is not Lisp numbers 1 and 2, but Maxima
bfloats or symbolic expressions).
CL floats have advantages for purely numerical calculations; perhaps the
better CL implementations even implement them as stack-allocated pairs of
floats in compiled code? How much is that advantage worth to us vs. the
complications resulting from allowing complexes within Maxima expressions?
-s
On Sun, Jul 31, 2011 at 21:06, R Fateman <fateman at eecs.berkeley.edu> wrote:
> On 7/31/2011 9:41 AM, Robert Dodier wrote:
>
>> Yup, that's a good list.
>> I've just taken one step -- maybe someone else wants to keep going.
>>
>> best
>>
>> Robert Dodier
>>
>>
>> I've thought about this some more, and I think it would be too messy to
> introduce CL complex in any central
> way in Maxima.
> 1. The CL notion is of a pair of reals. But Maxima has another real type,
> namely bigfloat, which is
> not acceptable as part of a CL complex. So the CL notion is inadequate for
> even numerical use
> in Maxima.
> 2. The notion of number in Maxima is extended further, to symbols and
> symbolic expressions.
> The CL complex notation is not adequate for pairs of arbitrary expressions.
> 3. It might make sense (or, at least, not much difference) to use
> internally #c(0 1) instead of $%i.
> Input and Output would be modified to show %i as before.
>
> note that in a+b*%i there is no a priori requirement that a and b be real
> or real-valued. So
> extending CL complex to allow symbolic real and imaginary parts would not
> be so great...
>
> realpart(a+b*%i) is not necessarily a . etc.
> 4, nothing much is gained. Maybe saving a little memory occasionally??
>
> If you want to package complex numbers for operations done in Fortran or C,
> that can be done at
> that interface, as appropriate.
>
> After further thought, my view is now:
> The list I gave in an earlier message should not be construed as a menu of
> what to do, but
> as a list of reasons that doing it would be so messy as to be a bad idea.
> Mathematica has
> a Complex number data type and even today it breaks many things to have it
> around.
>
> RJF
>
>
>
> ______________________________**_________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/**mailman/listinfo/maxima<http://www.math.utexas.edu/mailman/listinfo/maxima>;
>