axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Axiom-developer] Re: doyen


From: root
Subject: [Axiom-developer] Re: doyen
Date: Fri, 13 Oct 2006 21:18:48 -0400

The address@hidden mailing list is the best forum 
for this discussion. I've taken the liberty of copying your questions
and comments to the list so we can all contribute.

Alejandro Jakubi writes:

> A short time ago, by chance, I have came across with your page about
> the Doyen project:
> 
> http://daly.axiom-developer.org/doyen/

This was the original concept slide presentation. 
It has not been updated because it has still not been realized.
There are several efforts working toward the goal and the goal
is slowly shifting as more ideas come together (e.g. Sage).






> and later on, I have been found some more information distributed in several
> places like:
> 
> http://sourceforge.net/projects/doyencd
> 
> http://wiki.axiom-developer.org/DoyenCD

DoyenCD is the sourceforge project and is, in theory, independent of
Axiom. However all of the people working on it are closely associated
with the axiom project. 






> as well as posts in doyencd-developer Archives
> (http://sourceforge.net/mailarchive/forum.php?forum_id=45218), Axiom-math,
> etc.
> 
> I have also downloaded and burned the CDs from the iso files
> doyen04262005 and doyen081306.
> 
> Some comments on this subject follow in this email. And not to a
> forum/list, as I do not know which is the proper place. I see that
> http://wiki.axiom-developer.org/Doyen is not active (its last post
> was 29 Nov 2004), and doyen-developer does not seem to be right
> either as I am not developer and its archive shows answers to
> messages not there.

The primary developer, Alfredo Portes, is associated with the 
address@hidden list and most of the discussion related 
to the DoyenCD project happens here.




> Comments:
> 
> 1. Doyen and Maple ( doyencd-developer 2006-07-16)
> 
> > There are technical issues (which we do not yet know how to solve
> > since we don't have Maple) but we believe these will not be
> > difficult.
> 
> I have Maple, and I have tested a pair of things, that, I guess, are
> part of those technical issues.
> 
> a. I have booted with doyen081306, and as root copied the Maple 10
> directory of Debian Sarge 3.1 file system (/usr/local/maple10) to
> the same location on the Doyen file system. Maple worked fine (at
> least for my little test).
> 
> b. From the shell command line, a simple text file with Maple
> statements can be open by Classic or Standard (Java) GUI, with these
> statements in the worksheet, ready for execution.
> 







> >  However there are licensing issues that can take some time to resolve.
> 
> Yes, these issues are hard and I doubt that there could be any
> solution nearby. You may know that Maple 10 came with the new
> feature that its Flexlm licence file is linked to the hardware, for
> Linux its ethernet card identification. That is your licence is no
> longer yours, but only yours as long as you use a specific
> OS/hardware combination. Some changes require a new "activation" of
> the licence. And Maplesoft has committed very strongly to this
> licencing scheme. But, in particular, it makes impossible to use
> Maple on a Live CD that someone with licence may take anywhere. In
> fact, I have posted to the Mapleprimes forum:
> 
> http://www.mapleprimes.com/blog/will/news-discontinuation-of-maple-platforms
> 
> suggesting this possibility, but there was no answer.

The philosophy behind Doyen is that we are trying to create a
"computational science platform". This platform can be customized
for particular conferences. Speakers can develop literate programs 
(paper text and program code combined, ala Knuth) that run on the 
latest Doyen version. That allows the conference audience to use
the programs immediately and strongly enhances their ability to
use newly announced functionality.

In addition, the literate programming aspect of the development
keeps the research work with the program source text. That allows
people to study the theory and execute the source at the same time.
The current separation makes code nearly impossible to maintain.

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.

It also assumes that the Doyen CD contains all of the systems 
necessary to support the software requirements of various disciplines
such as math or physics. (Since each DoyenCD is specific to a field
it does not have to have all of the software for every conference).

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.

Other suggestions are welcome.






> 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.
>  
> I begin with a personal example. I have used several CAS along the
> time and started using Maple in '93/94. Some ammount of my research
> of that time was done with Maple V Release 3 for Win 3.1. I have
> kept those worksheets as well as worksheets made with every version
> of Maple that I have used since then. As they kept changing the
> worksheet format, language, libraries, etc, in most of the version
> changes, I have kept installed in my disk every Maple version that I
> had. And I have moved all of them along at every machine/disk/OS
> change.  Mainly, with the purpose of being able to reproduce the
> calculations that I did time ago, the way they were done.
> 
> But obsolecence makes this scheme break down. I have found that PCs
> do not work for more than seven years, in the mean. And newer
> hardware require newer OS. But new OSs bring new library versions
> that make older aplications stop working, etc.
> 
> In particular, this obsolesce hell makes impossible to run Maple V
> Release 3 in current swift machines because of a division by
> zero/overflow error. And for Linux versions it is much worse because
> of the fast pace of change. So, while I can run under Windows XP
> Maple V Release 4 (10 years old), under a current Linux distro (as
> required for my hardware) it seems impossible to run a version older
> than 4-5 years, except for running the Windows version using Wine...
> 
> And while it could be fairly argued that this obsolecence problem is
> more acute with comercial products as vendors want to sell their
> latest versions and do not care to support old ones (under the
> 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?
> 
> 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.


The issue here is broader than any one particular system. I've
proposed a project called the Computer Algebra Test Suite (CATS) which
would create a taxonomy similiar to the NIST numerical math standard.
This taxonomy would be for symbolic mathematics.

CATS would consist of well-documented mathematical problems with
proven solutions. Each computational mathematics system (Axiom,
Maple, MMA, etc) would then have a "reference" set of problems that
show their solution or lack of a solution. The combination of theory,
worked examples, and running code over a broad range of problems would
guarantee that there are "standard answers" from many systems.

CATS should properly be funded by NIST or INRIA or some other large
national funding source and should enlist computational mathematicians
to submit solved, proven problems, classified within the taxonomy.

I believe that this would have the beneficial effect of making
solutions "permanent". It would have the beneficial effect of giving a
firm basis for computational mathematics. Systems could be compared,
alternative answers could be argued (related, say, to the issue of
branch cuts for example). College Curriculum committees could
standardize courses around the taxonomy. System independent theory and
documentation could arise. Testing would be improved and the expertise
necessary for testing could be leveraged by several systems. The
ultimate benefit would be stable, reliable, reproducable results
within the bounds of the standard.

The 30 year horizon view demands some solution like CATS.




Of course, funding such an effort is highly unlikely.  NIST had no
money for new research the year I planned to propose such work.
Non-commercial, research funding for computational mathematics in the
U.S. seems unlikely. The NSF will not fund research in areas where
there is commercial activity even if it can be argued that this
standardization effort will never happen otherwise. Since I am
not associated with a European academy INRIA is out.  Commercial
funding also seems unlikely because it gives away competitive
advantage if you are free to use other systems with the guarantee that
they give standard answers (although being able to decide the "standard"
answer certainly gives an advantage).




I have collected the regression test suites from various systems and
started on the classification. When sufficiently far along I'll create
a new sourceforge project and hope to attract people to the effort.
My current effort involves a taxonomy of cases and solutions within the 
Risch/Trager/Bronstein integration algorithm.




> But if reproducibility of code execution cannot be implemented for
> more than a few years, the whole project of documenting papers with
> code looses a good amount of its appeal, at least in my vision. It
> may work in the short term, eg. at a conference as you say, but not
> as an enhacement of the current archiving systems, in the long
> term. I can take a book or paper written over a century ago, read it
> and reproduce the hand calculations that the author did then (in
> fact I have done so). But will a document containing computer
> calculations made today be reproduced automatically by the devices
> of the next century or beyond?

If you still have the bootable Doyen CD from the conference (and
the hardware can support it, perhaps in a virtual machine) then,
yes, you can still reproduce it. 

But the reality is no, you won't be able to reproduce it unless
we start thinking about the 30 year horizon issues. If something
like a CATS standard existed then you could guarantee that the
algorithms would still give the same answer on whatever system
you use. 

At the moment we are in the same position in computational
mathematics that we were with floating point systems in the early
60 and 70s. Every manufacturer tries to be clever and make their
own version. We need a standardization effort such as the one
led by Kahan but in the computational mathematics area. 





> 3. I was attracted to the idea of Doyen CD at first because it was
> suggested in http://daly.axiom-developer.org/doyen/ that it brings
> many CAS (presumably in the recent versions) already installed:
> 
> "Rosetta is a collection of free and open source computer algebra systems.
> There are, at this time, approximately 100 such packages."
> ...
> "IDEA 5: Combine Rosetta and Quantian
> 
> Now we begin to combine ideas. The combination of the Rosetta idea
> and the Quantian idea gives us a bootable CD for computer algebra."
> 
> 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.
> 

Many years ago I used to create and distribute "Rosetta CDs" which
contained all of the available systems. When Axiom was released I
dropped the Rosetta effort to bring Axiom back to life.

Doyen is the merger of the Rosetta CD idea, the wiki idea, the
literate programming idea, and the Live CD idea. It has taken time 
to create, almost exclusively the work of Alfredo Portes and Bill
Page. The few systems that are currently on the CD is not an
indication of future direction but a limitation of the effort to a
small number of testbed systems.

There are a lot of little complexities that need to be addressed.  The
original system was based on Knoppix (Debian) but in order to have
buy-in from RedHat it was retargetted to Redhat/Fedora. (It is hoped
that RedHat could be convinced to "sponsor" the distribution of these
Doyen scientific platform CDs at many computational science
conferences.) 

The wiki requires a local web server and a fair amount of
coordination. In addition, the wiki needs to know how to pass
information into and collect information from various systems.





I understand your disappointment but frankly I think the issue is
more related to your expectations than to the reality. I'm amazed
at the amount of work, the quality of the work, and the synergy of
effort from all of the people involved.

This is a brand new field, the collision of mathematics and computers.
Computational mathematics will be here forevermore, we're at the very
beginning of its history, and you're trying to measure it against
mathematics, a centuries-old field.

Try to keep your eyes on the 30 year horizon and ignore the short
term issues as they will be solved eventually. (Harder to do than
it looks when there is a broken system in front of me :-))

Tim Daly







reply via email to

[Prev in Thread] Current Thread [Next in Thread]