Navigation

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.

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
changelogs. 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

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

V. Muñoz and U. Persson. Interviews with three Fields
medalists. Notices of the American Mathematical Society,
54(3):405–410, 2007.

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.

Why did you write Sage from scratch, instead of using other existing software and/or libraries?¶

Sage was not written from scratch. Most of its underlying mathematics
functionalities are made possible through FOSS projects such as

Pari/GP — a computer algebra
system for fast computations in number theory.

Pynac — a modified version of GiNaC
that replaces the dependency on CLN by Python.

R — a language and environment for
statistical computing and graphics.

And many more too numerous to list here.

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.

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.

With so many bugs in Sage and hundreds of open tickets, why don’t you produce a stabilization release?¶

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/local/share/doc/sage/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: