Sage 3.0?

The main goals for 3.0, which we should aim to complete in Feb 2008 are:

(1) SOLARIS: Full Solaris 10 support on Opteron and Sparc,

(2) 3D: Excellent interactive 3d graphics from the notebook and command line by working with the Jmol project.

(3) DEMOS: A demos server with interactive web-based use of Sage for specific applications, along with a catalogue of 500 examples that illustrate Sage and drive traffic to sagemath.org.

(4) DOCTESTS: Raise the doctest coverage of the Sage library to 50%. (Right now it is at 35.5%).

The Growth of Open Source Mathematics Software

With help from Martin Albrecht, I've been tracking the traffic to sagemath.org.

Some of the above plots compare Sagemath.org to Maplesoft.com. Before the UW press release (inspired by Sage winning Trophees du Libre), sagemath.org traffic was insignificant when compared to Maple. On Dec 3 when the press release went out until Dec 11, there was a huge spike in traffic, so that sagemath.org went from being a speck to over twice the amount of traffic as Maple gets. NOTE -- this increase in traffic started two days before the slashdotting. On Dec 5 during the slashdotting, the number of downloads of sage itself went up a huge amount (thousands per day). This hump died down after about a week on December 11. However, the number of Sage users has gone up by quite a bit, and perhaps a nontrivial fraction of the people who tried Sage a week ago are now Sage users. Traffic to sagemath.org has gone from basically nothing as measured by Alexa to nontrivial in comparison to the other big Ma*'s.

Perhaps soon trac #1000 can be closed and replaced by a ticket to have 100,000 users?

Sage, Mathematica and Hiking to Vultee Arch

Here is an example of implementing a special function in Sage using Mathematica to do the real work:

def math_bessel_K(nu,x):
    return mathematica(nu).BesselK(x).N(20).sage()

sage: math_bessel_K(2,I)
0.180489972066962*I - 2.592886175491197

When I showed this to a Sage user they exclaimed:

> This is incredibly cool! I can't believe I missed this in the Sage
> reference manual, but there it is. In wonder how it works?

This blog post is about how the above works.

I figured out a clean way to have this sort of notation work in
Mathematica, etc., from Sage when I was hiking with my wife in Sedona to Vultee Arch a couple years ago. Basically when you do say

s = mathematica(nu)

Sage converts nu into a Mathematica-readable string by calling nu._mathematica_init_():

sage: nu = sqrt(2) + I*sin(3)
sage: nu._mathematica_init_()
'(Sqrt[2]) + ((I) * (Sin[3]))'

Note that _mathematica_init_ on the nu in the above example calls other _mathematica_init_'s, e.g., sqrt(2) has a mathematica_init_ method that calls that _mathematica_init_ method for 2, etc. Mathematica itself is not used at all yet. Incidentally, just like you can latex expressions, e.g.,

sage: latex(nu)
{i \cdot \sin \left( 3 \right)} + \sqrt{ 2 }

for inclusion in a paper or something, you can also mathematica them as above, to share with mathematica users...

Anyway Sage sends this string to mathematica:

'sage0 := (Sqrt[2]) + ((I) * (Sin[3]))'

Mathematica evaluates it and Sage creates a Python wrapper object, which knows the variable name 'sage0':

sage: s = mathematica(nu)
sage: s.name( )
'sage0'
sage: type(s)

sage: s
Sqrt[2] + I*Sin[3]

Now there is a running instance of mathematica, and it has an object defined in it
called sage0, which is equal to our nu:

sage: mathematica.eval('sage0')
Sqrt[2] + I Sin[3]


You can even play around with that copy of Mathematica more directly from the command
line (or with %mathematica in a cell in the Sage notebook):

sage: %mathematica

--> Switching to Mathematica <--

''
mathematica: sage0
Sqrt[2] + I*Sin[3]
mathematica: Sqrt[sage0]
Sqrt[Sqrt[2] + I*Sin[3]]
mathematica: N[sage0]
1.4142135623730951 + 0.1411200080598672*I

[[Note this is like the Mathematica command line but better since it has readline support, etc.]]

mathematica: %sage
--> Exiting back to SAGE <--

Finally, if you want to call a function and give the version of nu that is in Mathematica as an argument, you just call the function on it using Pythonic notation:

sage: s.Sqrt()
Sqrt[Sqrt[2] + I*Sin[3]]
sage: s.N()
1.4142135623730951 + 0.1411200080598672*I

What happens here is that say s.Sqrt creates a Python class that wraps the Mathematica function Sqrt with argument s not yet evaluated, so even this works:

sage: s.Sqrt?
Docstring:
Sqrt[z] or Sqrt[z] gives the square root of z.

When we did s.Sqrt? Sage queries Mathematica for how Sqrt works.

Everything above applies equally to the Maple, Matlab, Maxima, PARI, Singular, etc., interfaces. There is *much* that can be done to make the Mathematica interface in particular even more cool. Ideas appreciated!

By the way, it snowed very nicely on the hike, and my wife and I had a great time.

Fork GMP?

The suggestion to fork GMP seems to pop up regularly, due to some unfortunate ways in which that project currently runs. A fork of GMP would need a new name and might have the following goals:

• Have a regular release cycle,
  
• Officially support OS X and Microsoft Windows,
  
• Not be useable by Maple/Mathematica/Magma, i.e., change the license of the combined work from LGPL to GPL,
  
• Be very friendly to new developers and their ideas for patches,
  
• Have a referee system, since technical knowledge about the inner workings of GMP is quite difficult,
  
• Everything would done in public, with public mailing lists, code repositories, bug trackers, etc,
  
• And be binary compatible with the official GMP for as long as possible.
  

The fork might be called MPIR: Multi-Precision Integers and Rationals, which is a name that is similar to the name of MPFR, the floating point library that builds on top of GMP.

Let's hope that forking GMP is not necessary!

Why isn't Sage just part of Octave?

Here's a list of reasons that Sage and Octave are and will remain two very different projects, and also why I didn't initially join up with the Octave team when I started Sage three years ago:

(1) Octave doesn't do anything at all that is useful for any of my personal research, at least the research I was doing when I started Sage. I am a number theorist / arithmetic geometer, who works with elliptic curves, modular forms, prime numbers, arbitrary precision arithmetic, and high precision numerical
computation. There is almost zero overlap between anything I personally wanted to compute and anything Octave does, or even supports at a basic level. That's my personal reason.

(2) Octave is designed primarily to be a Matlab clone, and having programmed as a job seriously in Matlab for one year as a graduate student, I did not get the impression that the Matlab language was nearly so beautiful, well designed, expressive, etc., as Python, especially when one is interested in writing code to do a huge range of things -- networking, web servers, GUI's, symbolic algebra, etc., none of which is numerical computation. Since Octave's, language-wise at least, seems to me to be to clone Matlab's language, the same issues apply there.

(3) The goals for Sage are to provide a viable alternative to "Magma, Maple, Matlab, and Mathematica". The Magma system, which you might not have heard of, is a beautiful closed source commercial well-structured computer algebra system developed at the University of Sydney. For serious research mathematics in number theory it utterly blows away Maple, Mathematica, and Matlab. The entire design of Magma, which is the result of several decades of hard worked by many people, is completely foreign to the design of Octave/Matlab/Maple/Mathematica, but actually maps quite well to the Python programming language. Trying to implement something like Magma in the context of Octave would be too hard given how much time I have. To some extent similar remarks apply regarding Maple and Mathematica -- to write a viable alternative to Maple or Mathematica in Octave would likely be very difficult -- especially because the Octave language is really meant primarily for numerical/matrix calculations rather than symbolic algebra. Thus I think it would be too difficult to accomplish the primary mission of Sage using Octave.

(4) At some point though, I had to chose the numerical component for sage, since in fact my more recent research interests had broadened to more numerical things, and those of a lot of new Sage users (the number of Sage users increased by a huge amount in the last few months), were also fairly numerical. Given that I chose Python as the center of gravity for Sage, I had to find something that fit well with Python. The most natural choice is Scipy/Numpy, since it is a Python library supported by a successful company funding its development (http://www.enthought.com/), and having met the employees of that company I think it will stay successful. That said, I (and my student Josh Kantor) had substantial trouble -- which we eventually overcame through much hard work -- building Scipy from source on a wide range of platforms, so we tried very hard to make Octave serve as the numerical component of Sage. We found several things:

(a) Octave takes quite a long time to build from source -- easily 5-10 times as long as scipy. This is nearly a show stopper.

(b) Octave does not have a robust library mode. I.e., the only current way to use Octave from Python is via a psuedo-tty. This rendered Octave completely unsuitable as the main numerical core of SAge, unless we wanted to spend a massive amount of time fixing up the experimental half-way Octave C-library interface (we don't). And, at the end of the day, Octave basically mainly wraps the same libraries as Scipy already wraps.

(c) Any user interested in Python and numerical computation already very likely uses Scipy/Numpy, so trying to convince them to *switch* to using Sage and a shakie Octave interface would be futile.

All that said, I think Octave is a great program (more below), and there is a Sage <--> Octave interface, see:

sage: r = octave('rand(2)')
sage: r^2
 0.264001 0.336857
 0.198339 0.253094

and I'm very glad Octave exists. It's incredibly useful for people with Matlab programs that need to run them but don't want to use Matlab. But for the reasons listed above Sage has much different ambitions than Octave:

* Sage's goal is to be a viable alternative to Maple, Mathematica,
Magma, *and* Matlab (not just Matlab, which may be Octave's goal),

* finally be the first major math software system to use a standard
mainstream programming language (e.g., Python) instead of a
custom language, and one that is very good at gluing together
distinct systems.

* provide a home for and unified interface to the wide range of incredibly
powerful special-purpose software that specialists in number theory,
combinatorics, algebraic geometry, and so on have written.
(Sage ships with at least 10 such programs...)