-------- Original Message --------
Subject: Re: [Maxima] [PATCH] lisp ratio and bigfloat
Date: Fri, 27 Sep 2013 17:42:17 +0200
From: John Lapeyre <lapeyre.math122a at gmail.com>
To: Stavros Macrakis <macrakis at alum.mit.edu>
CC: maxima mailing list <maxima at math.utexas.edu>
> True, there are many things that do work, but it is not a good idea to count on it, as Maxima was
written assuming that anything that is numberp is either an integer or a
float.
That's true. I certainly don't think using lisp rationals and complex
should be relied on after making just a few changes.
I agree that there is a possibility of such code. It would be written
along these lines:
...
(cond ((atom x)
(cond ((symbolp x) .....
((integerp x) .....
(t ..... ;;; x must be a floating point number
which would be an error even without lisp numbers because there are already
other atomic types in Maxima that are allowed. arrays and strings come
to mind.
And yes, in fact, they can cause problems. We just had such an issue
last week.
Allowing common lisp numbers essentially at the "leaves" of the body of
the code
is less likely to encounter issues. E.g. input and output, or as John's
code does,
conversion to a well-known type like bigfloat.
The real change in Maxima that would sort of grow organically from
common lisp
would be to use object orientation and dispatch on the types of objects like
integers or $sin or $cos rather than looking at their CAARs. This
might be a
bad idea in terms of efficiency if the CL has a slow implementation of CLOS.
RJF
But some support
has already been included. For instance lisp rationals can already be
displayed. In nforma.lisp the code is commented with
;; in case a common lisp ratio is returned somehow.
;; in case a common lisp complex number is returned somehow.
My rationale is basically the same. For instance, if someone calls a
lisp library that returns some rationals and does arithmetic
operations with floats (already works) or bigfloats on the result;
great, it works. (If they do it with integers, there may be trouble
down the line.) Of course, you might argue that instead this code
should rather trap lisp rationals and issue a warning or error asking
the user to report to the developers because this is never supposed to
happen.
I do think it would be nice if maxima could take more advantage of
native lisp types. But, I don't necessarily think it should be
inserted into the main code branch. It's more of an experimental
idea. If enough changes like this were made, maybe some portions of
code would work with lisp rationals; or communicating with other lisp
libraries might be easier.
The main counterargument I can think of is: It would take a lot of
these small changes before it could be very useful. And in the
meantime, the complexity of the code is increased without benefit.
It's a reasonable argument. If it were up to me, I'd put it in. But,
I have no interest in persuading people to put it in the main branch.
--John
-------------- next part --------------
_______________________________________________
Maxima mailing list
Maxima at math.utexas.edu
http://www.math.utexas.edu/mailman/listinfo/maxima