"trigrat" caught in infinite loop - depending on how you call it

State is stored in more places than just symbols' values.  One possibility
is something in the 'assume' database (which is stored in symbols' plists
and is a circular list structure that gets modified in-place, so neither
equal nor eq are good ways of comparing two versions....

            -s

On Wed, Nov 7, 2012 at 12:27 PM, Jean-Claude ARBAUT <
jeanclaudearbaut at orange.fr> wrote:

> I tried something in lisp, maybe it can help (be indulgent, I'm learning
> lisp ;-))
>
>
>
> to_lisp();
>
>
>
> (defun allsymbols ()
> (let ((h (make-hash-table :test 'equal)))
>      (do-all-symbols (s) (if (boundp s) (setf (gethash s h) (symbol-value
> s))))
>      h))
>
>
>
> (defun diffhash (h1 h2)
>    (let ((v nil))
>       (maphash (lambda (k a)
>          (multiple-value-bind (b s) (gethash k h1)
>             (if (or (not s) (not (equal a b))) (setf v (cons k v)))))
>          h2)
>       v))
>
>
> (defvar blabla1)
>
>
>
> (defvar blabla2)
>
>
>
> (defun $bli1 () (setf blabla1 (allsymbols)))
>
> (defun $bli2 () (setf blabla2 (allsymbols)))
>
>
>
> (to-maxima)
>
>
>
> f: 1/(y+sqrt(y))$
>
>
>
> [bli1(), trigrat(f), bli2(), trigrat(f)];
>
> [bli1(), trigrat(f), bli2(), trigrat(f)];
>
>
>
> /* twice so that variables initialized once and for all are not counted */
>
>
>
> to_lisp();
>
>
>
> (diffhash blabla1 blabla2)
>
>
>
> And all I get is this (not counting BLABLA1 which is also modified of
> course):
>
>
>
> (*LAST-MEVAL1-FORM* *GENSYM-COUNTER* VARLIST)
>
>
>
>
>
> VARLIST is empty before the first call to trigrat, and after it has value
>
> (((MEXPT SIMP) $Y ((RAT SIMP) 1 2)) $Y)
>
>
>
> The other two don't seem to be interesting, I don't know for sure if
> VARLIST is,
>
> or if I missed something. HTH !
>
>
>
> Jean-Claude Arbaut
>
> > Message du 07/11/12 16:49
> > De : "Stavros Macrakis"
> > A : "David Scherfgen"
> > Copie ? : "maxima at math.utexas.edu"
> > Objet : Re: [Maxima] "trigrat" caught in infinite loop - depending on
> how you call it
>
> >
> > The fact that you have to use 'reset' indicates that there is a bug in
> trigrat.  It would be better to fix the bug than to try to work around it,
> but I suppose you could do a binary search of the settings that 'reset'
> resets....
>
> >
>             -s
> >
> >
> On Wed, Nov 7, 2012 at 10:46 AM, David Scherfgen <
> d.scherfgen at googlemail.com> wrote:
> >
>
>> Thanks for this nice observation.
>> > I found out that if you call "reset()" inbetween, it gives the short
>> answer both times:
>> >
>> > f: 1/(y+sqrt(y));
>> > [trigrat(f), reset(), trigrat(f)];
>> >
>> > But I think that "reset()" might be doing a bit too much.
>> > How could I find the minimum set of settings/variables that I have to
>> reset in order to make it work correctly?
>> >
>> > - David
>> >
>> >
>> > Am 07.11.2012 16:06, schrieb Stavros Macrakis:
>> >
>>
>>> trigrat apparently leaves some state around after exiting, which is
>>> bad...
>>> >
>>> > Starting from David's example, here is the simplest bad case I could
>>> find:
>>> >
>>> > f: 1/(y+sqrt(y))$
>>> >
>>> > [trigrat(f),trigrat(f)]  =>  [ , ]
>>>
>>> >
>>> > This doesn't lead to an infinite loop, but the two results are
>>> different when they should be the same.
>>> >
>>> > Tested in 5.27.0 2012-04-30 11:59:06 i686-apple-darwin11.3.0 SBCL
>>> 1.0.55.0-abb03f9
>>> >
>>> >     -s
>>> >
>>> >
>>>  On Wed, Nov 7, 2012 at 7:28 AM, David Scherfgen <
>>> d.scherfgen at googlemail.com d.scherfgen at googlemail.com>> wrote:
>>> >
>>> >     Hello Maxima users,
>>> >
>>> >     I have discovered a very strange bug in Maxima, which I am about
>>> >     to report on SourceForge.
>>> >     But nevertheless, I want to ask if any of you has come across this
>>> >     one or might be able to help me circumvent it.
>>> >
>>> >     The following works:
>>> >
>>> >     e : 2*x/(sqrt(y)+x) - (x^2/((sqrt(y)+x)^2));
>>> >     trigrat(e);
>>> >     trigrat(xthru(e));
>>> >
>>> >     But when I do this:
>>> >
>>> >     ( trigrat(e), trigrat(xthru(e)) )
>>> >
>>> >     or
>>> >
>>> >     [ trigrat(e), trigrat(xthru(e)) ]
>>> >
>>> >     the second "trigrat" call inside will hang, i.e. Maxima will run
>>> >     on 100% CPU and will never return.
>>> >     So: evaluating both lines separately works, but evaluating them
>>> >     together or inside a function will cause the "bug".
>>> >
>>> >     Strangely, everything works fine when I swap the expressions:
>>> >
>>> >     ( trigrat(e), trigrat(xthru(e)) );   /* loops forever */
>>> >     ( trigrat(xthru(e)), trigrat(e) );   /* works */
>>> >
>>> >     I can't find a pattern ... it seems very mysterious to me.
>>> >     Any idea what might be happening here?
>>> >
>>> >     Regards,
>>> >     David Scherfgen
>>> >     _______________________________________________
>>> >     Maxima mailing list
>>> >
>>>      Maxima at math.utexas.edu 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
>
>