On Fri, Oct 14, 2011 at 14:01, Panagiotis Papasotiriou <
p.j.papasot at gmail.com> wrote:
> 2011/10/14 Stavros Macrakis <macrakis at alum.mit.edu>
>
>> Could you provide a minimal example that reproduces the problem you/re
>> having? It sounds like you're doing fairly complicated things with dynamic
>> function definitions etc.
>
>
> My function, "rkf45", implements the Runge-Kutta-Fehleberg (4th-5th order)
> algorithm for solving initial-value problems. I was thinking it would be
> nice if it is added in maxima/share, as it supports automatic step size and
> error control.
>
Yes, that would be great!
Dynamic function definition is used only once in the code. It can be
> avoided,...
>
I wasn't suggesting that you avoid it. Just that it will be hard to help
you improve the compilation of the code without getting a reproducible (and
preferably small) example of the problem you're having.
> However, I was thinking that translating it to lisp would make it much
> faster.
>
Yes, it should, but the existing 'translate' function does a pretty good job
of that -- no need for manual translation.
> You should probably not declare list-valued variables at all.
>>
>
> Unfortunately, that's impossible. Actually, all dummy variables are (and
> must be) lists. So the question is, how can I mode_declare a list? And, if
> that's not possible, how can I get the same functionality?
>
I think you're misunderstanding my remark. You can certainly ***use***
list-valued variables. You should simply not mode_declare them; undeclared
variables can take any value of any type.
I don't know what you're using lists for, but if you're using them to
represent numeric vectors, that will not be good for performance (unless you
always traverse them left to right); random access in Maxima/Lisp lists is
relatively slow.
-s