

last edited 16 years ago 
1  
Editor:
Time: 2007/11/18 17:46:35 GMT8 

Note: detail axiom goals, directions, and practice 
changed:  Intent This page is an initial attempt at describing the goals and direction of the Axiom project. It is an open invitation for the Axiom community to participate and cooperate in getting a "back of the envelope" sketch of what the project hopes to achieve, and of how it is going to achieve it. For this page to have any meaning, I (Stephen), hope that others will feel free to edit, correct, and even rewrite anything that follows. Let this page evolve and grow without hesitation. It will be clear when it reaches a point where it can be said to accurately reflect the goals and principles of the Axiom project and community. The 30 Year Horizon Without a doubt, the essential guiding principle of the the Axiom project is the notion of the 30 Year Horizon. To quote from Timothy Daly, in the new forward to the Axiom book:: ... I've introduced the theme of the "30 year horizon". We must invent the tools that support the Computational Mathematician working 30 years from now. How will research be done when every bit of mathematical knowledge is online and instantly available? What happens when we scale Axiom by a factor of 100, giving us 1.1 million domains? How can we integrate theory with code? How will we integrate theorems and proofs of the mathematics with spacetime complexity proofs and running code? What visualization tools are needed? How do we support the conceptual structures and semantics of mathematics in effective ways? How do we support results from the sciences? How do we teach the next generation to be effective Computational Mathematicians? Axiom has always been, and will continue to be, a research platform and testbed for new ideas. Ideas which are aimed at pushing beyond what today is considered state of the art. A fundamental methodology has been adopted to enable the evolution of Axiom as both a working program and as an expression of knowledge. Axiom adheres to the principles of Literate Programming, which puts the documentation  or rather, the human understanding  first. The goal is to encapsulate the knowledge of Axiom's contributors so that the insights they posses can be understood by others both today and in 30 years time. Axiom is not just a program, it is a philosophy put into practice. Axiom is a very serious work. It aims at being correct, both in terms of its mathematical abilities but also in its implementation and architecture. All changes to the system, large or small, need to be carefully verified and checked. There is no hard and fast set of rules which states how verification is realized. However, there are two very general guidelines:  Nothing can replace the human eye and mind in determining if something is amiss, and changes to the system are actively scrutinized by the developers of the system.  Automated tools and test suites can lift ones confidence immeasurably. The Axiom project actively encourages the development of tests to improve reliability. And recommends that new changes to the system be accompanied by test cases whenever possible. The Community and Contributors Axiom is community driven, and is the sum of the efforts of its contributors. For the dedication and work of the individuals involved to be of most use to the community as a whole, Axiom requires that patches to the system be posted on the developer mailing list before they are committed to the system. Changes should make a good faith attempt to capture a particular concept  fix a particular bug, add a new feature, improve the documentation of a certain subsystem, etc. This is for the benefit of others, so that they may understand the logic behind the development. The strategy is also important for ensuring the correctness of the system, for when changes are made as a logical unit, the point where bugs might be introduced are much easier to isolate. In short, this policy is to ensure all involved have the opportunity to both study and work with a change of the system in a meaningful and productive way. The Axiom project actively encourages the design of new architectures and tools which enrich the system. It is never considered a waste of time to actively explore new approaches and implementations which have the goal of improving the system. Even if initial efforts do not immediately convince all minds that the direction has merit, the opportunity is open to everyone to try their hand at reaching for the 30 year horizon. Therefore, Axiom actively encourages the creation of branches  regions of independent development where an individual or group can pursue topics of interest. Branches exist to support experimental work, since such work needs space and time to evolve into robust facilities. But with this freedom comes a slight obligation  to contribute back, when possible, to the mainline of development. For any nontrivial branch, there is ample opportunity to publish changes which improve the main system directly. Furthermore, maintainers of such branches should make a good faith attempt to keep them in sync with the mainline of development, so as to not frustrate a merge into the canonical source when ready. The branches which are currently available are always listed on the AxiomSources page, together with links to more information detailing the ideas and motivation behind each branch. There is also a fork of the Axiom system, the 'FriCAS' project, which has set for itself different goals and methodologies. See: http://sourceforge.net/projects/fricas for more information about this effort.
This page is an initial attempt at describing the goals and direction of the Axiom project. It is an open invitation for the Axiom community to participate and cooperate in getting a "back of the envelope" sketch of what the project hopes to achieve, and of how it is going to achieve it.
For this page to have any meaning, I (Stephen), hope that others will feel free to edit, correct, and even rewrite anything that follows. Let this page evolve and grow without hesitation. It will be clear when it reaches a point where it can be said to accurately reflect the goals and principles of the Axiom project and community.
Without a doubt, the essential guiding principle of the the Axiom project is the notion of the 30 Year Horizon. To quote from Timothy Daly, in the new forward to the Axiom book:
... I've introduced the theme of the "30 year horizon". We must invent the tools that support the Computational Mathematician working 30 years from now. How will research be done when every bit of mathematical knowledge is online and instantly available? What happens when we scale Axiom by a factor of 100, giving us 1.1 million domains? How can we integrate theory with code? How will we integrate theorems and proofs of the mathematics with spacetime complexity proofs and running code? What visualization tools are needed? How do we support the conceptual structures and semantics of mathematics in effective ways? How do we support results from the sciences? How do we teach the next generation to be effective Computational Mathematicians?
Axiom has always been, and will continue to be, a research platform and testbed for new ideas. Ideas which are aimed at pushing beyond what today is considered state of the art.
A fundamental methodology has been adopted to enable the evolution of Axiom as both a working program and as an expression of knowledge. Axiom adheres to the principles of Literate Programming, which puts the documentation  or rather, the human understanding  first. The goal is to encapsulate the knowledge of Axiom's contributors so that the insights they posses can be understood by others both today and in 30 years time. Axiom is not just a program, it is a philosophy put into practice.
Axiom is a very serious work. It aims at being correct, both in terms of its mathematical abilities but also in its implementation and architecture. All changes to the system, large or small, need to be carefully verified and checked. There is no hard and fast set of rules which states how verification is realized. However, there are two very general guidelines:
Axiom is community driven, and is the sum of the efforts of its contributors. For the dedication and work of the individuals involved to be of most use to the community as a whole, Axiom requires that patches to the system be posted on the developer mailing list before they are committed to the system. Changes should make a good faith attempt to capture a particular concept  fix a particular bug, add a new feature, improve the documentation of a certain subsystem, etc. This is for the benefit of others, so that they may understand the logic behind the development. The strategy is also important for ensuring the correctness of the system, for when changes are made as a logical unit, the point where bugs might be introduced are much easier to isolate. In short, this policy is to ensure all involved have the opportunity to both study and work with a change of the system in a meaningful and productive way.
The Axiom project actively encourages the design of new architectures and tools which enrich the system. It is never considered a waste of time to actively explore new approaches and implementations which have the goal of improving the system. Even if initial efforts do not immediately convince all minds that the direction has merit, the opportunity is open to everyone to try their hand at reaching for the 30 year horizon. Therefore, Axiom actively encourages the creation of branches  regions of independent development where an individual or group can pursue topics of interest. Branches exist to support experimental work, since such work needs space and time to evolve into robust facilities. But with this freedom comes a slight obligation  to contribute back, when possible, to the mainline of development. For any nontrivial branch, there is ample opportunity to publish changes which improve the main system directly. Furthermore, maintainers of such branches should make a good faith attempt to keep them in sync with the mainline of development, so as to not frustrate a merge into the canonical source when ready.
The branches which are currently available are always listed on the AxiomSources page, together with links to more information detailing the ideas and motivation behind each branch.
There is also a fork of the Axiom system, the FriCAS
project, which has set
for itself different goals and methodologies.
See: http://sourceforge.net/projects/fricas for more information about this effort.