I'm away from a Maxima system, but here are some thoughts.
1. Great is not set up to deal with MRATs. Maybe the problem is in
simplification of such mixed items, though I am not sure what
this would lead to. eg. make foo(rat(1)) into the same as
rat(foo(1)) ...
2. Rather than run the MRAT through format, one could "ratdisrep" the
expression and add that form to the car of the MRAT, and save it there,
at least as long as the expression did not change value. e.g.
((mrat ..... disrepform ((mplus ..) ....) rest of stuff)
so great (or anyone else) who want to use this alternative has easy access..
One could also do this.
((mplus simp repform ((mrat ....))) ....) for fast access to the
rat() form of an expression..
I am traveling and haven't thought so much about it.
RJF
> 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
>