Yes, it seems it is the same bug, or at least caused by the same reason. The
only workaround I can think is to avoid dynamic function definition within
the translated code. Unfortunately. this would make the call of the function
more close to Fortran than what it is expected in a Computer Algebra System.
Maybe it is a better idea to leave the code untranslated, and publish it as
it is now. I am very curious to see how faster the translated code is,
though.
I will come back with more news on the subject soon.
Thank you for your help.
2011/10/14 Stavros Macrakis <macrakis at alum.mit.edu>
> Not sure if this is the *same* bug, but here is a bug in 'translate' that
> appears with a simpler case:
>
> f(vars):=define(funmake('f,vars),2)$
> f([a,b,c]); => f(a, b, c) := 2 OK
> translate(f)$
> f([a,b,c]);
> Maxima encountered a Lisp error:
> Error in $F [or a callee]: $F [or a callee] requires more than one
> argument.
>
> I suspect that the best workaround for this is to do anything involving
> funmake, define, etc. in interpreted code, and only use compiled code for
> the core computation.
>
> Unless of course someone is ready to roll up their sleeves and fix the bug.
> I wrote the original 'translate' in the 1970's, but the current one is
> completely different.
>
> -s
>