[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Axiom-developer] Re: FeynCalc -> MAXIMA
[Axiom-developer] Re: FeynCalc -> MAXIMA
21 May 2004 18:19:28 -0400
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
Greetings! Just my 0.02 here --
I think the concept of literate programming axiom has adopted is
marvelous. The need for providing a ladder whereby a human brain can
easily expand the realm of its comprehension into a new area of
interest without expensive infrastructure and in a reasonable period
of time exceeds the need for a black box to spit out an answer in
assembly line fashion, IMHO, though both needs obviously exist and
will continue to do so. As long as we're talking 30 years, I think
the real coup would be to provide a framework which smooths the path
stretching from one end of this continuum to the other, and
concommitantly, provides utility and access to as wide a group of
interested volunteers as possible, especially in this frenetic age
when one's available time is likely to come in erratic and
unpredicatable short bursts.
Tim Daly <address@hidden> writes:
> 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
Camm Maguire address@hidden
"The earth is but one country, and mankind its citizens." -- Baha'u'llah