This doesn't cause a problem in Maxima 5.23.2 GCL 2.6.8. What version are
you running? I wonder what has changed between the versions.
I suspect that the problem in your example below is that you are calling
(simplus x 1 t) and not (simplus x 1 nil). When the third arg to simplus is
T, it means that all the arguments of mplus have already been simplified,
which is not the case here. Given that the precondition is violated, I
wouldn't be surprised that great was called on something it shouldn't be
called on.
-s
On Tue, Aug 23, 2011 at 01:30, Robert Dodier <robert.dodier at gmail.com>wrote:
> Hi,
>
> I've found that this Lisp program:
>
> (defparameter x '((mplus) ((foo) ((mrat simp ($c) (#:c1635)) (#:c1635
> 1 -1) . 1) $a)
> ((foo) ((mrat simp nil nil) 1 . 1) ((mtimes simp) $a $b))))
> (simplus x 1 t)
>
> triggers an error: CAR: #:C1635 is not a list
>
> I see that GREAT uses MARGS to decompose the MRAT expressions,
> which leads to the error because MARGS is naive, it just returns
> the CDR of the expression.
>
> How should GREAT and/or MARGS handle MRAT?
> The simplest thing to do is to reformat the arguments of GREAT
> but I suspect that's too expensive.
>
> I guess that whatever we come up with should be applied to
> other expressions with special representations.
>
> Thanks for any light you can shed on this.
>
> Robert Dodier
>
>
> PS. I discovered the error like this:
>
> load (ezunits);
> x : (rat(1) ` a) * (1 ` b + c);
> expand (x);
> => "not a list" error
>
> When the error is triggered, * has been distributed over +
> and SIMPLUS is sorting the arguments, hence the call to GREAT.
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>