On Tue, Aug 2, 2011 at 01:34, Robert Dodier <robert.dodier at gmail.com> wrote:
> ...In general, I'd like to see Maxima take a laissez-faire attitude
> toward Lisp complexes and rationals.
> It's OK if Maxima doesn't know what to make of sin(z) where z is
> a Lisp complex or rational, but it's not OK if it triggers an error.
>
On the contrary. It is a horrible user experience to have 1/2 - 1/2 not
simplify to 0 because their internal form is different. If some code is
injecting a Lisp complex or rational into a Maxima expression, and we have
not updated Maxima to treat it correctly everywhere, then that is a bug, and
the sooner an error is reported for bugs like that, the better.
I claim the correct mathematical approach to unknown objects
> is to leave them alone; that way an interested party can devise
> the functions or identities or whatever to handle them.
>
First of all, we don't really treat Lisp 1/2 and #c(0 1) as opaque objects;
after all, they test positive for numberp, and that has consequences within
the Maxima code base. For example, (meval '(($ASSUME) ((MGREATERP) $Y #c(0
1)))) stack overflows; if #c(0 1) were really a completely opaque object, it
would not.
Secondly, there is no way within the Maxima language to generate Lisp
rationals and complexes; so why should Maxima handle them at all?
> Triggering an error is essentially a declaration that there can
> never be a way to handle the objects in question.
No. Triggering an error is a declaration that the preconditions for the
correct functioning of code are not met, and that from then on, the system
can't promise to deliver correct results.
I still don't understand the positive motivation for allowing Lisp complexes
as part of Maxima expressions. Is it so that we can use external functions
which allow complex arguments and return complex results? If so, why isn't
translating to and from Lisp complex just part of the normal interface
transformation -- just like translating Lisp arrays to Fortran arrays or
whatever.
-s