Stavros Macrakis wrote:
> Adding a simple clause to great for mbox doesn't seem like a big deal
> and it is actually pretty important for the user.
great already spends an inordinate amount of time on "mbox" .... it is
checked in the innermost loop...
here is a sketch of the program...
(defmfun great (x y)
(cond ((atom x)
(cond ((atom y)
;;; stuff omitted... comparing 2 atoms
((atom y) (ordfna x y)) ';; ordfna calls great recursively
;; check for rational numbers
((eq (caar x) 'rat)
(cond ((eq (caar y) 'rat)
(greaterp (times (caddr y) (cadr x)) (times (caddr x) (cadr y))))))
((eq (caar y) 'rat))
;; check for mbox or labelled box. Does anyone use labelled boxes???
((memq (caar x) '(mbox mlabox)) (great (cadr x) y) ****a****)
((memq (caar y) '(mbox mlabox)) (great x (cadr y)) ****b**** )
;; NOW check for the common cases of *, +, ^ and ??? %del??
((or (memq (caar x) '(mtimes mplus mexpt %del))
(memq (caar y) '(mtimes mplus mexpt %del)))
(ordfn x y))
((and (eq (caar x) 'bigfloat) (eq (caar y) 'bigfloat)) (mgrp x y))
;;; remaining case ... compare arguments of two equal functions. e.g.
sin(x) vs sin(y).
(t ;; more stuff)))
now any change that is in the clauses marked ****a***** or ****b**** is
not going to matter,
it would be better to eliminate those two containing clauses.
One idea for speeding up 'great' is 'memoizing' ...
Asking if (for non-atoms) great has already been run on these arguments
and then
just recalling the answer that has been previously computed.
Another requires computing a kind of sorting "hashcode" for every
expression. Maple does this,
using "address in memory", and using that for ordering.
Rjf
>
> adding a box to an expression to reorder its parts.
>
> On 2010-06-13, Richard Fateman <fateman at cs.berkeley.edu> wrote:
>> If neg produces simplified results, then this would be a bug in 'great'.
>> and it would have to be fixed.
>>
>> I assumed neg had a bug in it and that it doesn't produce simplified results
>> and that replacing neg as Barton suggests would fix it.
>> For example,
>> :lisp (defun neg(x)(mul x -1))
>>
>> and see if that fixes it. But that doesn't fix it.
>>
>> So the bug is in great, involving mboxes.
>>
>> Rather than clutter great with more checks on mboxes, a feature that is
>> rarely used,
>> maybe we can simply decide that ((mbox) E) is 'greater' than E, and
>> eliminate
>> all special checks on mboxes.
>>
>> RJF
>>
>>
>> _______________________________________________
>> Maxima mailing list
>> Maxima at math.utexas.edu
>> http://www.math.utexas.edu/mailman/listinfo/maxima
>>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima