On 12/10/2012 8:07 AM, Robert Dodier wrote:
> On 2012-12-10, Richard Fateman <fateman at gmail.com> wrote:
>
>> The function GREAT should not be called on MRATs.
>> If it is called on MRATs then the function calling it is in error.
>>
>> It is not a good idea to have GREAT do a totaldisrep on its arguments.
>> GREAT is called many times, and totaldisrep would be called many times.
> OK, that makes sense to me. How about if we put a test for MRAT into
> GREAT so that it triggers a more specific error. E.g. have it throw
> HEY-NO-MRATS-PLEASE or merror("GREAT: dunno about MRAT") or something.
>
> best
>
> Robert Dodier
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
Well, it would be better to do this for a debugging run to find out what
program is making this mistake, and then fix that program.
e.g. temporarily redefine...
:lisp (defun great(x y)(if (or (and(listp x)(eq (caar x 'mrat))) (and
(listp y)(eq (caar y) 'mrat)))
(break "please debug the program
calling great") (previouslydefinedgreat x y)))
Since it is (I think) not a 'user' error, in my opinion, it is
not polite to blurt out at the user an error message that he/she
presumably has no chance of fixing.
Making GREAT run slower, even a little, by doing a check that is
not necessary except during debugging, is irksome.
I've tried to vastly reduce the dependency of the simplifier on
calls to GREAT, but with mixed success. As I recall, it depends
on the quality of the hashtable implementation in the underlying
lisp. GREAT is used to compute "simplified" ordering of terms.
If this can be computed by computing a hash code of each expression
and storing the ordering in a table, simplification of sums and products
and some other things can be made orders of magnitude faster.
(and faster than Maple, which is otherwise usually faster than Maxima)
Demonstrably so, in some lisps. but not others.