Re: [Axiom-developer] Re: doyen

[CY]

On Friday 13 October 2006 21:18, root wrote:

> Clearly this involves a lot of "assumed infrastructure". It assumes
> that literate programs will show up at conferences.  Carlo Traverso
> (Univ. of Pisa, Math Dept. Chair) is working to create a new, referred
> Journal that accepts and reviews literate programs. These would likely
> be distributed and run on a Doyen-like platform.

Very interesting!  Out of curiosity, what would be the licensing conditions 
for the papers and code in this journal?  Could they be incorporated into the 
Axiom system?

> Since Maple is one of the primary computational mathematics tools it
> would be good to be able to support literate programs that implement
> algorithms using Maple.
>
> I've had discussions with Jurgen Gerhard of Maplesoft about the
> licensing issue. We do not yet have an agreed solution to the
> problem. Perhaps their new licensing scheme will allow us to create
> "custom" Doyen CDs that have keys which are registered to conference
> attendees. That would complicate the Doyen CD production but might
> make it acceptable to Maple.

Perhaps it would be simpler to have a license server running at the conference 
which the Doyen CDs for that conference would query in order to activate 
Maple?  That might be less work, since it would only require one server and 
the CD being (slightly) smart.

In the long run I would think the 30 year horizon would be better served by 
encouraging computation mathematics to center on open source platforms for 
research work, but I concede the viability of that approach is not yet 
demonstrated.

> > 2. I have seen posts related to short-term goals like setting up a
> > local wiki And also posts related to the long-term ("The 30 Year
> > Horizon"). However, I have not seen any post on a problem that affects
> > this science documentation initiative already in the mid-term (few
> > years), namely reproducibility. This is: the same output from the same
> > input, at any time, for every calculation.

This is an interesting problem in general, and I would argue it cannot be 
supported by the current computational infrastructure.

As your own story demonstrates, computer algebra software must rest on 
supporting programs, and changes or breakage in those layers impacts the 
computer algebra as well.  Very broadly, the stack is:

Computer algebra software
                   |
Implementation Language (Lisp, in our case.  GCL adds additional 
requirements.)
                   |
    Operating System, drivers
                   |
      Physical Hardware

We don't control most of these layers, and there are relatively few guarantees 
in terms of behavior or consistency.  The Physical Hardware has to satisfy 
fairly rigorous performance and consistency criteria in order to function on 
even a basic level, but the operating system doesn't really do so.  Lisp has 
the ANSI standard, but Axiom is not current written in ANSI lisp.  And our 
internal languages, BOOT and SPAD, have no specification.  All of this makes 
things more difficult.

The only solution I can see which might come even close to addressing this is 
to provide formal proofs of behavior for key behaviors at all layers, both 
behaviors provided and behaviors required.  Then any new system or 
implementation which can produce proofs supporting those behaviors can be 
trusted.

This would require a hardening of the semantics of languages used to implement 
the foundations, and extensive formal proof work for both language designs 
and implementations.  While I personally find this idea interesting for the 
purpose of being able to truly re-use and trust code in the future, there 
does not seem to be much motivation on the commercial side.  It would be 
monumental and very expensive, and current solutions are "good enough".

> > upgrade! motto). The cicles of OS/hardware changes unavoidably hit
> > open free software as well. And you could tell me better, for cases
> > like Axiom, with a small amount of volunteer developers, where would
> > you alocate those limited resources? on development or on patching
> > previous versions?

Open source software in general can track changes to the underlying systems, 
and a behavior change from one version to the next would be regarded as a 
bug. (Or maybe a fixed bug, depending.)  New versions would contain patches 
to new systems.

> > More specifically, calculations made with Axiom, Maxima, etc,
> > version 2006 will not be able to be reproduced within 30 years or a
> > century unless you could make these 2006 version application work in
> > that future OS/hardware whatever it is like, exactly the same as
> > they did initially. Or if you could manage to simulate in Axiom,
> > Maxima, etc, version 2036 exactly the behavior of its
> > ancestor. Frankly I am pessimistic that something like that could be
> > achieved.

One doesn't always want to achieve that.  The first question to be asked 
should be "is this new behavior wrong, or was the old behavior wrong?"  (In 
more subtle cases - obviously a crash is wrong.)  It is possible the 2006 
result was wrong.  That's actually an objection I have heard in the past to 
computer algebra - "how do I know it's right?"  In my opinion answering that 
question is the biggest challenge computer algebra will face going forward.

That this question must be asked is unfortunate, but the trustworthy 
infrastructure that would allow us to to guarantee consistent and correct 
behavior just doesn't exist yet.

> > etc. But doyen04262005 brings just these systems: Axiom, Yacas,
> > Octave, Maxima and Magnus, as far as I could see, and doyen081306
> > Axiom, Maxima and Magnus.
> >
> > I have to say that I was a little disappointed with what I have
> > found inside.

FWIW, I think it is safe to say that Axiom and Maxima represent the two most 
powerful general purpose open source computer algebra systems available. 

To me, the real frustration is that there should be so many different systems 
implementing what are in effect different pieces of the same puzzle.  
Different conventions and "environmental" assumptions (some of which might 
not even be noticed) make moving from one system to another difficult as a 
general problem.  Why shouldn't it be possible to do all of this work inside 
one larger, robust, and powerful framework?  Then each new algorithm and tool 
would be immediately available for use in any new work.

Axiom's design gives me hope for this goal - it appears to be designed 
generally enough that it can scale.  But there are many years of work ahead 
to make it a well documented and robust system.

Cheers,
CY