|
From: Raymond T. <toy...@gm...> - 2018-06-06 23:02:54
|
>>>>> "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
|