To illustrate one of the pitfalls, consider the well-known
books "Numerical Recipes in X" for various programming languages
X (Fortran, C, Pascal, Lisp??).
Some people are very enthusiastic about these books, but they
are usually people who area not experts in numerical methods.
The attraction of the recipes is that they are easy to understand.
The problem with the recipes is that they are easy to understand,
and are therefore not robust and/or efficient.
An analogy might be to airplanes. You probably feel safer
in a Boeing 747 -- a plane which is too complicated for you to
understand, but which has been extensively tested,
than an ultra-light airplane using a lawn-mower engine and
built out of wood and nylon fabric. Even though the ultra-light
airplane might be understandable to you.
You can use an algorithm copied out of Numerical recipes, (or
from von zur Gathen's Modern Computer Algebra,) but these would be like
the ultra-light version. Containing the 10% of the code that
does most of the problem, most of the time, but sweeps some
problems under the rug.
If you want something engineered to be robust and efficient,
you will have to look elsewhere, perhaps in Maxima, Axiom, etc.
Or maybe not even in those systems.
besides which, if you have theory and code together, they
may not be mutually supportive. One of the problems is
that they may not even agree!
A better approach may be to have the code derived automatically
and correctly from the theory, and then automatically optimized.
A difficult problem in general, but something done in part
by compilers.
RJF
Stavros Macrakis wrote:
>>We need to keep the theory and the code together and have
>>each one explain the other. How else can you show that the
>>code does what it is intended to do?
>>
>>
>
>That is a very hard problem in general.
>
>Good algorithms (as opposed to naïve ones) are often connected to theory
>in complicated ways -- just look at published algorithms. Then the
>practical implementation of the algorithm is often connected to the
>published algorithm in complicated ways.
>
>"Literate programming" is effective when the algorithm has a nice
>hierarchical structure, but there are many tricks that good algorithm
>designers and programmers use which don't fit well into that structure.
>Some years ago, I participated in a conference on transformational
>programming where Tarjan talked about this... it was humbling.
>
>Personally, I think this is a fascinating area, but it really is a
>research problem in itself. So if your goal is solving physics/math
>problems, I would recommend that you be pragmatic about how far you go
>in trying to systematize the transition from theory to code.
>
> -s
>
>_______________________________________________
>Maxima mailing list
>Maxima@www.math.utexas.edu
>http://www.math.utexas.edu/mailman/listinfo/maxima
>
>
This archive was generated by hypermail 2b29 : 09/04/20-12:55:05 AM Z CEST