# [Maxima] Lisp stack overflow

Stavros Macrakis 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...!

-s

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)
>     ((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
>
>
```