Thanks, I was doing this on a couple other files and checking the
UNLISP file just now did help me catch some variables I forgot to put
in the block local variables list.
So in my example I see:
/* The following functions are not known to be translated.
[lu_factor,lu_backsub]$ */
in the UNLISP file, and
(setq $M (simplify (mfunction-call $lu_factor $A)))
in the LISP file. Does that mean lu_factor is already compiled, and
the generated LISP just calls the same function I would be calling
from a normal Maxima session? Inverting the matrix is probably the big
pole in this function, so if compiling doesn't change that part it
probably isn't worthwhile in this case; useful as a learning example
though.
On Fri, May 22, 2009 at 11:49 AM, Barton Willis <willisb at unk.edu> wrote:
> By the way:
>
> Compiling Maxima code that does a great deal of IEEE floating point or
> fixed integer arithmetic can greatly reduce execution time (you'll
> need to use mode_declare); however, compilation rarely helps code that
> does mostly symbolic work.
>
> Compiling Maxima code is a good way to catch some bugs---look at the
> .UNLISP file.
>
> Barton
>
>
>
>
--
Joshua Stults
Website: http://j-stults.blogspot.com