[Maxima] Lisp stack overflow
macrakis at alum.mit.edu
Sun Jun 13 20:27:02 CDT 2010
It seems to me that checking (memq (caar X) '(...)) is a trivial
amount of time (two pointer comparisons against constants!), even in
the inner loop of great. So trivial that I wouldn't even bother to
measure it... But if you have numbers, let's see them...!
On 2010-06-13, Richard Fateman <fateman at cs.berkeley.edu> wrote:
> 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.
>> 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
>>> 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
>>> all special checks on mboxes.
>>> Maxima mailing list
>>> Maxima at math.utexas.edu
>> Maxima mailing list
>> Maxima at math.utexas.edu
More information about the Maxima