Re: [Axiom-developer] sbcl and Axiom

[root]

CY,

There are many volumes planned for axiom so there are many places to play.

One key subgoal that is completely independent is to figure out how to
draw a line on the screen using SBCL or CLISP and the new lisp-based GUI
work. planet.lisp.org has had several discussions about this. A lisp-based
GUI for graphics would be much more portable.

As I look around the local swamp I have several projects "in process".
Each one is running in a locally modified version of Axiom and is not
ready for merging into the main branch.

I have a project to redo HyperDoc using javascript and XMLHttpRequest.
This uses a browser as the front end for the hyperdoc pages and uses
an axiom back end to service requests for actions. Eventually this will
go into the Doyen Wiki. I've rewritten a couple dozen pages so far and
am working test examples.

I have a project to document the integration routines in axiom. I have
several sources of text (Trager's thesis, Bronstein's thesis, etc) as
well as 4800 integrals that came from the Maple test suite (reported
on elsewhere in this mailing list). I've modified axiom to tell me
where each integral resolves and am classifying the various integrals
into sets of examples. That way each of the 40ish 'integrate' routines
will have example input associated with it.

I have a project to port axiom to the MAC. The key issue is getting GCL
to build on the MAC. Since MACs are based on BSD the include file chain
is completely different from linux and so things resolve poorly. Plus
I find the MAC impossible to use (my ability to use a system is 
inversely proportional to its "ease of use").

I have a project to document the interpreter and reduce it to a book
(volume 5). Currently I'm reverse engineering and documenting the
ptree and pf2sex structures and functions. This is the primary 
seam between the parser and the axiom internals.

I have a project to write a literate program for drag-and-drop.
This involves figuring out how to handle drag-and-drop in a browser
(there is a drag-and-drop event in javascript) as well as choosing
a technical paper that will be simple enough to illustrate the idea.
Two papers are competing for that, one is "Primes is in P" and the
other is on denesting radicals.

I have a project to add the numeric libraries back into Axiom.  Axiom
is now a member of the Numerical Mathematics Consortium.  As a side
effect, I'm rewriting the routines into literate form, finding
research papers explaining the theory, such as convergence and
sensitivity, and adding that to the documentation. I'm currently
making the BLAS library literate.

I have a research effort to rewrite the algebra using provisos.
This uses the idea of generalized intervals to contain conditional
statements that constrain the validity of computations.


There are many, many other projects that could be done. For instance,

 * choose one of the book volumes and work on it

    - vol 2 is on programming. lately there has been a lot of discussion
      about programming in aldor. some of the same questions apply to
      spad code. there needs to be a lot of work given to explaining
      how to code algebra for axiom. i wrote a tutorial for how to
      develop a simple domain in aldor (it might be on the aldor site).
      this could be adapted to spad code and put into volume 2 as a
      chapter.

    - vol 3 is a reference guide. there are hundreds of hours of work
      here, following the example of the original Jenks book. Each 
      domain needs an explanation, a coverage of its exported functions,
      and example code. The explanations would also fit into the source
      files for the domain and the examples could be added to the input
      test suite.

    - vol 4 is the developer's guide. there are a large number of
      ideas cached in this mailing list that need explaining. there
      needs to be a step-by-step explanation of the make process
      (and the makefile.pamphlets can use the same text).

    - vol 6 is the compiler. Start with the )compile command and
      figure out how it works. Document it. Rewrite it. Package it
      as a volume.

    - vol 7 is the hyperdoc browser. This needs to be documented,
      rewritten, and packaged. Ideally it would be rewritten using one
      of the lisp GUI tools.

    - vol 8 is the graphics. Again, this needs to be documented,
      rewritten, and packaged. Ideally it would be rewritten using one
      of the lisp GUI tools.

    - vol 9 is the algebra. There is a whole wonderland of problems here.
      We can't even graph the lattice of the algebra reasonably. Pick
      any domain, document its purpose, functions, and give example code.
      Rewrite it so it can be drag-and-dropped. 

Volume 1, the tutorial, needs to be translated to other languages.

Axiom needs an example domain-specific literate book, like linear
algebra or signal processing, or music that can be an example of a
drag-and-drop domain expertise.

The database design in Axiom is old. It uses random access files which
follow VM/370 LispVM design. These databases should be redone using a
better overall design.

The NRLIB design needs rework. This is a copy of the LispVM compile
structure and should go away.

The NRLIB/code.lsp file has a large number of conventions. These need
to be defined and explained. There should be a low-level browser for
these files. 

How does Axiom generate Latex? Can we use the same mechanism to 
generate MathML?

The input directory should go away and the input tests should be
merged with their corresponding algebra source files. The machinery
now exists and has a couple examples. The input examples should be 
explained and made comprehensive.

There is a book "CRC Standard Curves and Surfaces" which contains
hundreds of worked-out examples of equations and their curves. This
should be made into a test suite (I have a start on this effort in
the CATS (Computer Algebra Test Suite) effort). We need to ensure that
Axiom's graphing routines generate the correct output and we need a
comprehensive test suite.

Axiom needs updated Groebner basis work (although the current routines
performed quite well at ISSAC 2006 when compared to singular and maple)

Axiom needs higher functions in the algebra, for instance, polylogs.

Axiom needs Symbolic Summation (extensions of Gosper's work)

Axiom needs much stronger algorithms in group theory.

Axiom needs generalization of its input format. For instance you should
pbe able to do:
   x := [ a_1, a_2, ..., a_n ] 
(in general for vectors or matrices). You should be able to ask for
the ith element of x, e.g. get(x,5) => x_5

Axiom needs to be able to do higher-order expressions like:
   x := p^n * 3*p^m + 2
   y := q^r * 6*q^s - 3
what is the j'th term of x*y? Well, since the we don't know the
exponents (n, m, r, or s) we have to construct a function that
will return the k'th component of x, the i'th component of y and
a final function that gives the result of x*y as a function of
the component functions. f(x(k),y(i)). Nobody does this yet to 
my knowledge.

If X is an 2x2 matrix what is X^p? If x is NxM what is X^p?
What is the i,j'th entry?

Can we construct a Maple parser that will generate Axiom internal
S-expressions? This would allow us to replace the Axiom input language
with a Maple input language. Is this useful? Is this better than B#?

If we decorate the Categories with their mathematical axioms can
we prove anything about them? Can we do it automatically using ACL2?
Can we extend the compiler to do the proof while it compiles?

Can we define a "problem graph" semantic network that will sit at the
heart of the crystal? What is the subsumption rule and is it theoretically
sound and stable?

Axiom should be attached to a Computer Aided Design program to 
model the stresses and strains and theoretical failure points.

Axiom should be integrated into a game like Bridge Builder
(http://www.bridgebuilder-game.com/pfx-info.php
to attempt to predict when a bridge might fail by computing the
result and then checking the simulation.

Axiom does not use threads or multiple processors but this is 
clearly the future direction of hardware. We need to find algorithms
that can be done in parallel and work up an example that gives linear
speedups based on the number of processors.

And that's just the short list off the top of my head.

t