**Next message:**Bertfried Fauser: "Re: [Axiom-developer] Re: FeynCalc -> MAXIMA"**Previous message:**Bertfried Fauser: "RE: [Maxima] Re: [Axiom-developer] Re: FeynCalc -> MAXIMA"**Next in thread:**Bertfried Fauser: "Re: FeynCalc -> MAXIMA"**Reply:**Bertfried Fauser: "Re: FeynCalc -> MAXIMA"**Reply:**C Y: "Re: [Axiom-developer] FeynCalc -> MAXIMA"**Reply:**Camm Maguire: "Re: FeynCalc -> MAXIMA"**Messages sorted by:**[ date ] [ thread ] [ subject ] [ author ]**Mail actions:**[ respond to this message ] [ mail a new topic ]

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

document).

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

axiom@tenkan.org

daly@idsi.net

**Next message:**Bertfried Fauser: "Re: [Axiom-developer] Re: FeynCalc -> MAXIMA"**Previous message:**Bertfried Fauser: "RE: [Maxima] Re: [Axiom-developer] Re: FeynCalc -> MAXIMA"**Next in thread:**Bertfried Fauser: "Re: FeynCalc -> MAXIMA"**Reply:**Bertfried Fauser: "Re: FeynCalc -> MAXIMA"**Reply:**C Y: "Re: [Axiom-developer] FeynCalc -> MAXIMA"**Reply:**Camm Maguire: "Re: FeynCalc -> MAXIMA"**Messages sorted by:**[ date ] [ thread ] [ subject ] [ author ]**Mail actions:**[ respond to this message ] [ mail a new topic ]

*
This archive was generated by hypermail 2b29
: 03/29/17-03:20:03 AM Z CEST
*