On 5/31/07, Barton Willis <willisb at unk.edu> wrote:
>
> Sometimes, I think that more of Maxima should be written in Maxima.
As Wolfgang suggests, part of it is comfort with the language. As a
language, I generally prefer Lisp to Maxima, though as soon as you start
writing mathematical formulae, Maxima's infix syntax makes it handier.
The speed advantages of CL over Maxima aren't all that great for symbolic
> work.
I think it's useful to think of Maxima as a layered system, though of course
that structure isn't explicit in the code. You have the low-level
simplification, algebraic, comparison, and arithmetic routines; then the
routines that use those to perform more complicated functions like equation
solving, matrix operations, and integration; and finally application code
which uses those to solve the user's problem. There is also of course the
Maxima programming infrastructure including both the interpreter and the
translator; those are on a different dimension in some way.
I believe it is worthwhile to keep the low-level routines fast both in their
algorithms and their implementation, as sometimes the scale of problem that
can be solved depends on it -- not to mention simple response time for
things like plotting. It may well be useful for some symbolic calculation
to assume then retract millions of assumptions over dozens of variables, for
example. One component we are missing at this level is a fast, general
pattern-matcher or unifier, so the middle-level routines end up doing too
much of that "by hand".
In the middle routines, the quality of the algorithm tends to be more
important than the details of the implementation. On the other hand, they
may depend on data structures or operations (especially destructive list
operations) for efficiency. Maxima doesn't provide those, partly because
they are considered too low-level and too dangerous for the non-programmer.
And finally in user code, the algorithm is pretty much all that matters.
What tends to make code slow here is intermediate expression explosion more
than the micro-efficiency of the programming constructs. For example,
getting the order of variable elimination right may easily make the
difference between a solvable and an unsolvable problem. Still, it would be
nice if the translator were better....
That's for symbolic work. For heavily numeric applications, things are
quite different. There are many user-written numeric problems where
efficiency does matter. And my impression is that the translator actually
is tuned pretty well for those cases, as long as you include full
declarations and use the right kind of arrays.
Well, those are my thoughts off the top of my head.
-s