On Dec 12, 2007 3:22 PM, Thomas Keller <> wrote: > Hi, > I just saw the Dr. Dobb's article on SAGE. I will check it out, but I was > wondering if you've looked at Octave? > Why not join up with that team?
Here's a list of reasons that Sage and Octave are and will remain to 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 is 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...) -- William --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
