Complex numbers would need some careful consideration.
Some experimentation with Allegro CL suggests that
both the real and imag parts are
1. integer or rational
2. double precision float
3. single precision float
excluded are ... bigfloats, intervals.
Possible additional values are NaNs of size double or single.
We would need to still have encodings for a+b*i, for symbols
or bignums a and b. or intervals a, b if we ever get around
to those.
But in a+b*i, the i could be the complex unit #c(0 1), displayed
perhaps as %I or maybe something nicer to look at, like bold-roman i.
We already deal with a kind of inconsistency for quasi-rational numbers in
maxima. 1/2 is encoded as ((rat simp) 1 2) but
a/b is ((mtimes simp) $a ((mexpt simp) $b -1))
We could, I suppose, propose a new type (e.g. using CLOS) which would
be maxima number, and rewrite all the code that tests for number to
use this instead.
Note that some operations like GCD, LCM, do not work on all such numbers,
at least officially, so we might, within the notion of number, distinguish
those that are members of the real, complex, rational .. fields; those
that are in the ring of integers, members of finite fields [though they
look just like integers], maybe Euclidean domains, unique factorization
domains
etc.
This begins to look like Axiom.
RJF
Raymond Toy wrote:
>>>>>>"Richard" == Richard Fateman <fateman@cs.berkeley.edu> writes:
>>>>>>
>>>>>>
>
> Richard> For some programs I've written in common lisp and want
> Richard> to use with maxima, it would really help if we had an
>
> Richard> Introduction into Maxima code of the common lisp
> Richard> constructions for
> Richard> (a) rational numbers
> Richard> and
> Richard> (b) complex numbers
>
> Richard> My guess is that the only way to do this is for
> Richard> someone to make a good effort to replace ((rat) 1 2)
> Richard> etc everywhere with common lisp 1/2 ... created by (/ 1 2)
>
> Richard> and similar changes to a+b*%i for numerical a,b.
>
>Having a common lisp representation would certainly make some
>functions much easier to read and write.
>
>How do you expect to handle complex numbers? Common Lisp doesn't
>allow you to have mixed types for the real and imaginary component.
>It certainly won't handle complex numbers with bigfloat parts.
>
>Ray
>
>
>