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 _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer