[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Axiom-developer] FeynCalc -> MAXIMA
[Axiom-developer] FeynCalc -> MAXIMA
Wed, 19 May 2004 10:52:25 -0400
I know this is a research problem though hardly one that merits papers
on the subject, I guess.
My goal isn't to solve physics/math problems. My goal is to build a system
that will be used by computational mathematicians 30 years from now. Once
this is the stated goal several things become clear.
One clear problem that every system suffers from is that the research
papers are disconnected from the code. Mathematicians do the research
and programmers do the code. Usually it is the same person with two
mindsets. So the math mindset writes the theory with theorems and
proofs then publishes it, possibly making claims (with no way to
verify the claims by others). The programmer mindset writes the code
which hopefully correctly implements the theory but never publishes it.
Or publishes it as a "contribution" to some system.
Consider the issues this raises for computational mathematicians.
First, claims are made which cannot be reproduced. Citing results of
the program runs without presenting the programs is equivalent to
citing theorems without providing proofs. How can a referee properly
review such work? Physics and chemistry require reproduced results
before claims are accepted.
Second, the programs are either not available or published as
contributions. In the first case who is to know if the actual reason
for an algorithmic speedup turns out to be a compiler switch rather
than some theoretical reason like term ordering in a groebner basis
computation? Since it is unpublished the code is likely to die thus
undermining both the basis for the claim and the possibility that
other researchers can build on the work.
The second case is even worse in some sense. I have 1100 domains
in Axiom (some of which I wrote) and 100+ algorithms in Magnus
with no theoretical documentation; indeed most have no documentation
at all. In the 30 year view how is the next generation supposed to
build upon the work we've done so far? How can they see the evolution
of algorithms? How can they maintain the code without the theory?
Axiom represents over 30 years and over 300 man-years of research.
I don't believe that there will be funding to build systems that are
this large and this general. Even if one funded such an effort we
end up with a lot of rework that virtually no-one wants to do.
So I'm proposing a goal for the 30 year horizon. We need to make an
effort to collect the theory and the code and reunite the two. I
realize that there are issues.
One issue is, as you point out, that code has to deal with grubby
details which the theory can skip. But real design choices are made
when reducing theory to practice and these design choices greatly
affect the results. We need to encourage the practice of explaining
these design decisions. For example, how are infinite objects (like
groups) represented? We have learned that in simple domains like
polynomials there are a wide range of design choices (dense, sparse,
recursive, etc) that are appropriate for different problems.
Another issue is that current systems don't "reach up" close enough to
the theory. The gap between the theory and the implementation (I call
it the impedance mismatch) is too large for most systems. For
instance, Magnus is implemented in C++ which is WAY too close to the
machine and very, very far away from Infinite Group Theory (the Magnus
domain). Thus the burden of crossing this gap falls on the
programmer. Systems like Axiom are much closer to the mathematics. But
not close enough. We need systems that span this gap in carefully
structured ways so we can be efficient without being obscure.
This is one of the root causes of your comment that "the
practical implementation of the algorithm is often connected to the
published algorithm in complicated ways". The implemented algorithm
should not be much longer than the published one.
If we look at the 30 year horizon it is clear that all papers in
computational mathematics will be online. We must set standards
now, or at least strive for good examples, that make it possible
to use the research effectively. In today's terms we should be
able to "drag and drop" a computational mathematics paper onto
a system like Axiom and have it immediately available. (In 30
year terms Axiom should know the "intentional stance" of the
researcher and automatically incorporate the algorithms).
One of the key problems is that "Computational Mathematics" is
like "Computer Science" was 30 years ago. Comp Sci was a branch
of the Math dept (numerical analysis), Engineering (circuit
minimization), or Business (spreadsheets). It was not recognized
as its own subject with yet.
Today Computational Mathematics is growing out of Math (research
papers with no code), Comp Sci (research papers in polynomial
representation), Physics (clifford algebras, hopf algebras), or
Engineering (matrix methods), etc. It is not recognized as its
own subject yet (at least not everywhere. Risc-Linz, UWO, Waterloo,
and a few other places seem to have done so).
My current religious zealotism and wild-eyed, irrational planning
(I admit it's over-the-top-painful) claim is that we need to start
with an old idea "Literate Programming" and evolve it to suit the
needs of the next generation Computational Mathematician. Thus
all of Axiom (and soon Magnus) has been rewritten into TeX documents.
There are no C, Lisp, Spad, Makefile, etc files. Now I'm trying to
ensure that new code added to the system includes the theory (or
at least permission to use the paper so I can write the literate
Thus I would really like to see the papers that provide the theory for
FeynCalc as well as the code. If I can write one of the algorithms in
Axiom in a few dozen lines that would be much clearer than a few
thousand lines of C and I'd have the research paper attached.
It's a hard problem but we have 30 years to solve it.
Tim "the 30 year horizon" Daly