Re: [Maxima-discuss] out of memory error due to translate, was: Fatal error

[Raymond T. <toy...@gm...>]

>>>>> "Robert" == Robert Dodier <rob...@gm...> writes:

    Robert> On 2018-06-05, Michel Talon <ta...@lp...> wrote:
    >> Indeed tracing translate shows that the above calls repeatedly translate 
    >> on f_rk_4.   One gets things such as:
    >> 1 Enter translate [translate(f_rk_4)]
    >> 1 Exit  translate [f_rk_4]
    >> 1 Enter translate [translate(f_rk_4)]
    >> 1 Exit  translate [f_rk_4]
    >> 1 Enter translate [translate(f_rk_4)]
    >> 1 Exit  translate [f_rk_4]
    >> 1 Enter translate [translate(f_rk_4)]
    >> 1 Exit  translate [f_rk_4]
    >> 1 Enter translate [translate(f_rk_4)]
    >> 1 Exit  translate [f_rk_4]
    >> 1 Enter translate [translate(f_rk_4)]
    >> ...
    >> Which seems to point to an error in the invocation of translate.

    Robert> I don't think there's any programming error in drawdf. It's constructing
    Robert> a lot of little functions (all with the same name) and translating them.
    Robert> There's no reason to think it shouldn't work.

    >> and more importantly the above example now runs to completion in around 
    >> 10s.  So i think it is advisable to remove the call to translate
    >> in make_f_rk_4 that is  so that the last line is:
    >>         [dxdt_var,dydt_var]))))$

    Robert> I agree that 'translate' has no substantial benefit in this case, but
    Robert> running out of memory after only 1000 calls suggests a bug in Maxima or
    Robert> in SBCL or at least a restrictive, possibly unstated assumption
    Robert> somewhere. I will investigate a little more.

Interestingly, cmucl draws the graph (with a 512 MB heap) but it takes
a very long time (many tens of sec).  ccl64 does this in like 2 sec.
Possibly related to the fact that ccl's compiler is really really
fast.

There might be an advantage if key parts of drawdf were written in
lisp.  Maybe.

--
Ray