This is a rather minimal example. It doesn't do anything useful by itself,
but it demonstrates the problem:
foo(odes,funcs,initial,interval):=block(
[xi,yi],
mode_declare([xi,yi],any),
xi:interval[2],
yi:initial,
define(funmake(f_rhs,cons(interval[1],funcs)),odes),
apply(f_rhs,cons(xi,yi))
)$
Now, if you execute that code then trying, for example,
foo([x+y],[y],[1],[x,2]);
you get [3], as expected: with that call of foo, funcs=x+y, xi=[2], yi=[1],
so apply(f_rhs,cons(xi,yi)) should return 2+1=3. Now, if you try to
translate the code you get the error:
cons: 2nd argument must be a non-atomic expression; found funcs
Apparently, translator complains about the line
define(funmake(f_rhs,cons(interval[1],funcs)),odes),
Here, funcs is the 2nd argument of cons, and as such, it should be a list,
but the translator doesn't know this is the case. I tried to mode_declare
funcs as "any" or as "list", although funcs is a dummy variable, and manual
says only local variables should be mode_declare'd. It didn't work.
Furthermore, mode_declare doesn't say anything about declaring lists.
Note that in this example, funcs is a list of only one element for the sake
of simplicity; in the real code, it can be a list of many elements.
2011/10/14 Stavros Macrakis <macrakis at alum.mit.edu>
> 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
>