The stated mission of Sage is to be viable free open source alternative to Magma, Maple, Mathematica, and Matlab. Sage’s predecessors, known as HECKE and Manin, came about because William Stein needed to write them as part of his research in number theory. Started by William in 2005 during his time at Harvard University, Sage combines best-of-breed free open source mathematics software, packaging and unifying them through a common interface. Since then Sage has become something used not just by researchers in number theory, but throughout the mathematical sciences.
Sage builds upon and extends functionalities of many underlying packages. Even from early on, when Sage was primarily used for number theory, this included Givaro, MPIR, NTL, Pari/GP, and many others too numerous to list here. Students, teachers, professors, researchers throughout the world use Sage because they require a comprehensive free open source mathematics package that offers symbolic and numerical computation. Most of the time, people are happy with what Sage has to offer.
As is common throughout the free open source software (FOSS) world, many people often identify cases where Sage lacks certain mathematics functionalities that they require. And so they delve into the underlying source code that comprises Sage in order to extend it for their purposes, or expose functionalities of underlying packages shipped with Sage in order to use their favourite mathematics software packages from within Sage. The Sage-Combinat team is comprised of researchers in algebraic combinatorics. The team’s stated mission is to improve Sage as an extensible toolbox for computer exploration in algebraic combinatorics, and foster code sharing between researchers in this area.
For detailed information about why Sage exists, see William’s personal mathematics software biography.
In the first few years of Sage’s existence, the project was called “SAGE”. This acronym stood for “Software for Algebra and Geometry Experimentation”. Starting around 2007 and early 2008, the name “Sage” was widely adopted. Think of “Sage” as a name for a free open source mathematics software project, just as “Python” is a name for a free open source general purpose programming language. Whenever possible, please use the name “Sage” instead of “SAGE” to avoid confusing the Sage project with a computer project called SAGE. You pronounce “Sage” similar to how you would pronounce “sage” which refers to a wise person, or “sage” which refers to a plant. Some people pronounce “Sage” as “sarge”, similar to how you would pronounce Debian Sarge.
However you pronounce “Sage”, please do not confuse the Sage project with an accounting software by the same name.
Sage is a volunteer based project. Its success is due to the voluntary effort of a large international team of students, teachers, professors, researchers, software engineers, and people working in diverse areas of mathematics, science, engineering, software development, and all levels of education. The development of Sage has benefited from the financial support of numerous institutions, and the previous and ongoing work of many authors of included components.
A list of (some) direct contributors can be found on the Sage Development Map and the history of changes can be found in the high-level changelog. Refer to the acknowledgment page of the Sage website for an up-to-date list of financial and infrastructure supporters, mirror network hosting providers, and indirect contributors.
A standard rule in the mathematics community is that everything is laid open for inspection. The Sage project believes that not doing the same for mathematics software is at best a gesture of impoliteness and rudeness, and at worst a violation against standard scientific practices. An underlying philosophical principle of Sage is to apply the system of open exchange and peer review that characterizes scientific communication to the development of mathematics software. Neither the Sage project nor the Sage Development Team make any claims to being the original proponents of this principle.
The development model of Sage is largely inspired by the free software movement as spearheaded by the Free Software Foundation, and by the open source movement. One source of inspiration from within the mathematics community is Joachim Neubüser as expressed in the paper
and in particular the following quotation from his paper:
You can read Sylow's Theorem and its proof in Huppert's book in the library without even buying the book and then you can use Sylow's Theorem for the rest of your life free of charge, but...for many computer algebra systems license fees have to be paid regularly for the total time of their use. In order to protect what you pay for, you do not get the source, but only an executable, i.e. a black box. You can press buttons and you get answers in the same way as you get the bright pictures from your television set but you cannot control how they were made in either case. With this situation two of the most basic rules of conduct in mathematics are violated: In mathematics information is passed on free of charge and everything is laid open for checking. Not applying these rules to computer algebra systems that are made for mathematical research...means moving in a most undesirable direction. Most important: Can we expect somebody to believe a result of a program that he is not allowed to see? Moreover: Do we really want to charge colleagues in Moldava several years of their salary for a computer algebra system?
Similar sentiments were also expressed by Andrei Okounkov as can be found in
in particular the following quotation:
Computers are no more a threat to mathematicians than food processors are a threat to cooks. As mathematics gets more and more complex while the pace of our lives accelerates, we must delegate as much as we can to machines. And I mean both numeric and symbolic work. Some people can manage without dishwashers, but I think proofs come out a lot cleaner when routine work is automated. This brings up many issues. I am not an expert, but I think we need a symbolic standard to make computer manipulations easier to document and verify. And with all due respect to the free market, perhaps we should not be dependent on commercial software here. An open-source project could, perhaps, find better answers to the obvious problems such as availability, bugs, backward compatibility, platform independence, standard libraries, etc. One can learn from the success of TeX and more specialized software like Macaulay2. I do hope that funding agencies are looking into this.
Sage was not written from scratch. Most of its underlying mathematics functionalities are made possible through FOSS projects such as
An up-to-date list can be found on the page for the standard packages repository. The principle programming languages of Sage are Python and Cython. Python is the primary programming and interfacing language, while Cython is the primary language for optimizing critical functionalities and interfacing with C libraries and C extensions for Python. Sage integrates over 90 FOSS packages into a common interface. On top of these packages is the Sage library, which consists of over 700,000 lines of new Python and Cython code. See openhub.net for source code analysis of the latest stable Sage release.
For support about usage of Sage, there are two options:
For support about development of Sage, there is an email list sage-devel
See http://www.sagemath.org/help.html for a listing of other resources.
This topic has been discussed over and over again. So before you resume the discussion, ensure you have read and understood the arguments below. Sage is a distribution of over 90 FOSS packages for symbolic, numerical, and scientific computation. In general, the combinatorial explosion of configurations to debug is way too large. It is next to impossible to find any Linux distribution (e.g. Arch, CentOS, Debian, Fedora, Gentoo, Mandriva, Ubuntu) where the version numbers of packages that Sage depends on even remotely match.
The majority of people who contribute to Sage do so in their free time. These are people who hold day jobs that are not directly related to computer programming or software development. It is next to impossible for anyone to track down the correct versions of packages, configure and compile them on Linux, Mac OS X, Solaris, or Windows, just so that they could start using Sage or start working on their first contribution to Sage. While the Sage project aims to be useful to as wide an audience as possible, we believe that Sage first needs to be as easy as possible to install by anyone with any level of computer experience. If you want to help Sage realize this goal, please email the sage-devel mailing list.
Any software package contains bug. With something as complex as Sage, neither the Sage community nor the Sage Development Team make any claims that Sage is free of bugs. To do so would be an act of dishonesty.
A Sage release cycle usually lasts for a few months, with several betas appearing at a 2-3 week intervals. Each release cycle is usually chaired by a single release manager who looks after the Sage merge tree for the duration of the release cycle. During that time, the release manager often needs to devote the equivalent of full-time work to quality management and actively interacts with an international community of Sage users, developers, and potential contributors.
There have been a number of cases where two Sage contributors paired up to be the release managers for a Sage release cycle. However, it is often the case that few people have the equivalent of 3 weeks’ worth of free time to devote to release management. If you want to help out with release management, please subscribe to the sage-release mailing list.
Since the beginning of the Sage project, Sage contributors have tried to listen and think about what would increase the chances that serious potential contributors would actually contribute. What encourages one contributor can discourage another, so tradeoffs need to be made. To decide that a stabilization release would merge patches with bug fixes, and only fix bugs, would likely discourage someone from contributing when they have been told in advance that their positively reviewed patches will not be merged.
The Sage community believes in the principle of “release early, release often”. How the Sage project is organized and run differ greatly from that of a commercial software company. Contributors are all volunteers and this changes the dynamic of the project dramatically from what it would be if Sage were a commercial development effort with all developers being full-time employees.
To download the Sage standard documentation in HTML or PDF formats, visit the Help and Support page on the Sage website. Each release of Sage comes with the full documentation that makes up the Sage standard documentation. If you have downloaded a binary Sage release, the HTML version of the corresponding documentation comes pre-built and can be found under the directory SAGE_ROOT/src/doc/output/html/. During the compilation of Sage from source, the HTML version of the documentation is also built in the process. To build the HTML version of the documentation, issue the following command from SAGE_ROOT:
$ ./sage -docbuild --no-pdf-links all html
Building the PDF version requires that your system has a working LaTeX installation. To build the PDF version of the documentation, issue the following command from SAGE_ROOT:
$ ./sage -docbuild all pdf
For more command line options, refer to the output of any of the following commands:
$ ./sage -help $ ./sage -advanced