### Re: jacobian not listed

2007-05-31 23:49:31 GMT

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

_______________________________________________ Maxima mailing list Maxima <at> math.utexas.edu http://www.math.utexas.edu/mailman/listinfo/maxima