Navigation
- index
- next |
- previous |
- Sage FAQ v4.5.1 »
You can try out Sage without downloading anything. Go to http://www.sagenb.org and set up a free account. If you log in, you will be working on a free Sage notebook server that will work identically to the one you get with Sage. To download a pre-built binary Sage distribution, visit the page http://www.sagemath.org/download.html and click on the link for the binary for your operating system. The source code of Sage is also available for you to download and use. Go to http://www.sagemath.org/download-source.html to download the tar archive for any release of Sage. Previous releases of Sage are available at http://www.sagemath.org/src-old.
The Sage notebook runs within a web browser. You can run Sage in a browser that is not the system default. To do so, issue the following command
env SAGE_BROWSER=opera /usr/bin/sage -notebook
either from the command prompt or as a menu command for Sage.
Most of the dependencies of Sage are shipped with Sage itself. In most cases, you can download a pre-built binary and use that without installing any dependencies. If you use Windows, you will need to install VirtualBox, which can be downloaded from the page http://www.virtualbox.org/wiki/Downloads. After installing VirtualBox, you need to download a VirtualBox distribution of Sage available at http://www.sagemath.org/download-windows.html. Ensure you follow the instructions at that page. Now you can start the Sage virtual machine using the VirtualBox software, wait for the virtual machine to boot up, then type notebook at the prompt.
You can get the complete source for Sage to compile it on your own Linux or Mac OS X system. Sage lives in an isolated directory and does not interfere with your surrounding system. It ships together with everything necessary to develop Sage, the source code, all its dependencies and the complete changelog. On Linux systems like Debian/Ubuntu, you may have to install the build essential package, the m4 macro processor, and gfortran. Your system needs to have a working GCC installation (gcc, g++, and gfortran) if you want to compile Sage from source. So far, Sage has not been successfully built with a compiler suite other than GCC. You might also consider installing the readline package and its corresponding development headers. These packages make it easier to work with the Sage command line interface by providing text editing features at the command line level. On Debian/Ubuntu, you can install these prerequisites as follows:
sudo apt-get install build-essential m4 gfortran
sudo apt-get install readline-common libreadline-dev
If you have a multi-core system, you can opt for a parallel build of Sage. The command
export MAKE='make -j8'
will enable 8 threads for parts of the build that support parallelism. Change the number 8 as appropriate to suit the number of cores on your system.
It may be that you have Tcl/Tk installed and that your system’s Python recognizes it but Sage’s Python does not. To fix that, install the tcl/tk development library. On Ubuntu, this is the command
sudo apt-get install tk8.5-dev
or something along that line. Next, reinstall Sage’s Python:
sage -f python-2.5.2.p8
Replace the part “2.5.2.p8” with the exact version number as appropriate. This will pick up the tcl/tk library automatically. After successfully reinstalling Sage’s Python, from within the Sage command line interface, issue these commands:
import _tkinter
import Tkinter
If they do not raise an ImportError then it worked.
You can import Sage as a library in a Python script. One caveat is that you need to run that Python script using the version of Python that is bundled with Sage; currently Python 2.6.x. To import Sage, put the following in your Python script:
from sage.all import *
When you want to run your script, you need to invoke Sage with the option -python which would run your script using the version of Python that comes with Sage. For example, if Sage is in your PATH variable then you can do this:
sage -python /path/to/my/script.py
Another way is to write a Sage script and run that script using Sage itself. A Sage script has the file extension .sage and is more or less a Python script but uses Sage-specific functions and commands. You can then run that Sage script like so:
sage /path/to/my/script.sage
This will take care of loading the necessary environment variables and default imports for you.
You can load a Python script in a Sage session with the command load. For example, we could use Sage to import a file called simple.py with:
load("simple.py")
and repeat this command every time that we change the fiel simple.py. However, if we type:
attach("simple.py")
every change applied to the file simple.py will be automatically updated in Sage.
Currently, no. Sage depends on the SciPy stack of Python numerical and scientific packages. As of 2010, SciPy still uses Python 2.x. So until SciPy is ported to run with Python 3.x and Cython supports Python 3.x, Sage will continue to use Python 2.x.
When sage is built from source, it keeps track of what special instructions your CPU supports (such as SSE2) and records these. This is so that if you try running the code on a different machine, which does not support these extra instructions, you get a sensible error message instead of a segfault or illegal instruction. Since this should be stored with Sage itself (as opposed to a user’s .sage directory), it has to be created by someone with the appropriate permissions. So if you are seeing something like this
Traceback (most recent call last):
File "/usr/local/sage-4.0.2/local/bin/sage-location", line 174, in <module>
t, R = install_moved()
File "/usr/local/sage-4.0.2/local/bin/sage-location", line 18, in install_moved
write_flags_file()
File "/usr/local/sage-4.0.2/local/bin/sage-location", line 82, in write_flags_file
open(flags_file,'w').write(get_flags_info())
IOError: [Errno 13] Permission denied:
'/usr/local/sage-4.0.2/local/lib/sage-flags.txt'
it probably means that you compiled/installed Sage as one user, but have not run it to let it generate the sage-flags.txt file. Just run Sage one time as whatever user installed it and this problem should go away. This would also be easy to fix by having Sage run once as part of the install process; see trac ticket #6375 for this fix.
One way to fix this is to build Sage entirely from source. Another option is to fix your Sage installation by rebuilding MPIR and ATLAS by typing the following from the SAGE_ROOT of your Sage installation directory and wait about 15 to 20 minutes:
rm spkg/installed/mpir* spkg/installed/atlas*
make
It is possible that the binaries have been built for a newer architecture than what you have. Nobody has yet figured out how to build Sage in such a way that MPIR and ATLAS work on all hardware. This will eventually get fixed. Any help is appreciated.
The version of Sage, i.e. Sage version 3.0.5, that is available through apt-get in Debian and Ubuntu is very old. No one has yet found time to update the Debian/Ubuntu version of Sage. Any help is greatly appreciated. You should download the latest version of Sage from the download page. If you would like to help with updating the Debian/Ubuntu version of Sage, please email the sage-devel mailing list.
You are encouraged to use the latest official version of Sage. Development versions are frequently announced on the sage-devel and sage-release mailing lists. An easy way of helping out with Sage development is to download the latest development release, compile it on your system, run all doctests, and report any compilation errors or doctest failures.
Basic features of Sage should be as easy to learn as learning the basics of Python. Numerous tutorials are available online to help you learn Sage. To get the most out of Sage, you are encouraged to learn some features of the Python programming language. Here is an incomplete list of resources on Python. Further resources can be found by a web search.
You are encouraged to use Sage’s tab autocompletion. Just type a few characters, hit the tab key, and see if the command you want appears in the list of tab autocompletion. If you have a command called mycmd, then type mycmd. and hit the tab key to get a list of functionalities that are supported by that command. To read the documentation of mycmd, type mycmd? and press the enter key to read the documentation for that command. Similarly, type mycmd?? and hit the enter key to get the source code of that command. You are also encouraged to search through the source code and documentation of the Sage library. To search through the source code of the Sage library, use the command search_src("<search-keyword>") where you should replace <search-keyword> with the key words you are looking for. Also, you can search through the documentation of the Sage library using the command search_doc("<search-keyword>").
When you type “0.6**2” in Python, it returns something like 0.35999999999999999. But when you do the same in Sage it returns 0.360000000000000. To understand why Python behaves as it does, see the Python Tutorial, especially the chapter “Floating Point Arithmetic: Issues and Limitations”. What Sage does is “preparse” the input and transforms it like this:
sage: preparse("0.6**2")
"RealNumber('0.6')**Integer(2)"
So what is actually run is:
RealNumber('0.6')**Integer(2)
The Sage developers (in fact, Carl Witty) decided that Sage floating point numbers should by default print only the known correct decimal digits, when possible, thus skirting the problem that Python has. This decision has its pros and cons. Note that RealNumber and Integer are Sage specific, so you would not be able to just type the above into Python and expect it to work without first an import statement such as:
from sage.all import RealNumber, Integer, preparse
Using Sage, you are missing a feature of the Magma command line interface. In Magma, if you enter a line found in history using up arrow key and then press down arrow key, then the next line in history is fetched. This feature allows you to fetch as many successive lines in history as you like. However, Sage does not have a similar feature. The IPython command prompt uses the readline library (via pyreadline), which evidently does not support this feature. Magma has its own custom “readline-like” library, which does support this feature. (Since so many people have requested this feature, if anybody can figure out how to implement it, then such an implementation would certainly be welcome!)
You are using SciPy or cvxopt or NumPy from Sage and you get type errors, e.g.
TypeError: function not supported for these types, and can't coerce safely to supported types.
When you type in numbers into Sage, the pre-processor converts them to a base ring, which you can see by doing:
sage: preparse("stats.uniform(0,15).ppf([0.5,0.7])")
"stats.uniform(Integer(0),Integer(15)).ppf([RealNumber('0.5'),RealNumber('0.7')])"
Unfortunately, NumPy support of these advanced Sage types like Integer or RealNumber is not yet at 100%. As a solution, redefine RealNumber and/or Integer to change the behavior of the Sage preparser, so decimal literals are floats instead of Sage arbitrary precision real numbers, and integer literals are Python ints. For example:
sage: RealNumber = float; Integer = int
sage: from scipy import stats
sage: stats.ttest_ind(list([1,2,3,4,5]),list([2,3,4,5,.6]))
doctest...DeprecationWarning...
(0.076752955645333687, 0.94070490247380478)
sage: stats.uniform(0,15).ppf([0.5,0.7])
array([ 7.5, 10.5])
Alternatively, be explicit about data types, e.g.
sage: from scipy import stats
sage: stats.uniform(int(0),int(15)).ppf([float(0.5),float(0.7)])
array([ 7.5, 10.5])
As a third alternative, use the raw suffix:
sage: from scipy import stats
sage: stats.uniform(0r,15r).ppf([0.5r,0.7r])
array([ 7.5, 10.5])
You can also disable the preprocessor in your code via preparse(False). You can may start IPython alone from the command line sage -ipython which does not pre-load anything Sage-specific. Or switching the Notebook language to “Python”.
The save and load commands will save and load an object, respectively. In the notebook, the DATA variable is the location of the data storage area of the worksheet. To save the object my_stuff in a worksheet, you could do
save(my_stuff, DATA + "my_stuff")
and to reload it, you would just do
my_stuff = load(DATA + "my_stuff")
If you see the error
It looks like jsMath failed to set up properly (error code -7). I will try to keep going, but it could get ugly.
you have not installed the TeX fonts which help jsMath render beautiful typeset mathematics. To get the nice TeX display with jsMath, please download a set of fonts from here from http://www.math.union.edu/~dpvc/jsMath/download/jsMath-fonts.html. If you are on Linux/Unix, ignore the instructions on the page and just unzip the fonts into your ~/.fonts directory. You can also install the jsmath-fonts package.
Delete both of the file
SAGE_ROOT/devel/sage/build/sage/calculus/stokes.py
and the file
SAGE_ROOT/devel/sage/build/lib.*/sage/calculus/stokes.py
You might want to convert ASCII characters such as “Big Mac” to ASCII numerals for further processing. In Sage and Python, you can use ord, e.g.
sage: map(ord, "abcde")
[97, 98, 99, 100, 101]
sage: map(ord, "Big Mac")
[66, 105, 103, 32, 77, 97, 99]
Yes, just make a file $HOME/.sage/init.sage and it will be executed any time you start Sage. This assumes that the Sage environment variable DOT_SAGE points to the hidden directory $HOME/.sage, which by default is the case.
Moving a Sage install on Mac OS X 10.4 and then upgrading anything that is linked against NTL leads to link errors due to missing gmp symbols. The problem is the link mode with which the dynamic NTL is created. There is have a fix, but it still being verified that it really fixes the issue. Everything that is linked against NTL needs to be recompiled, i.e. singular and cremona at the moment. To add to the confusion: This is not an issue on Mac OS X 10.5. A fix for this issue went into Sage 2.8.15, so please report if you see this with a more current Sage release.
Compiling Sage is quite taxing on the CPU. The above behavior usually indicates that your computer has overheated. In many cases this can be fixed by cleaning the CPU fan and assuring proper ventilation of the system. Please ask your system administrator or a professional to do this in case you have never done this. Such hardware maintenance, if not performed by a skilled professional, you can potentially damage your system.
For Linux users, if you suspect that the compilation fails because of a resource issue, a fix might be to edit your /etc/inittab so that Linux boots into run level 3. The file /etc/inittab usually contains something similar to the following snippet:
# 0 - halt (Do NOT set initdefault to this)
# 1 - Single user mode
# 2 - Multiuser, without NFS (The same as 3, if you do not have
# networking)
# 3 - Full multiuser mode
# 4 - unused
# 5 - X11
# 6 - reboot (Do NOT set initdefault to this)
#
id:5:initdefault:
which directs your Linux distribution to boot into a graphical login screen. Comment out the line id:5:initdefault: and add the line id:3:initdefault:, so that you now have something like:
# 0 - halt (Do NOT set initdefault to this)
# 1 - Single user mode
# 2 - Multiuser, without NFS (The same as 3, if you do not have
# networking)
# 3 - Full multiuser mode
# 4 - unused
# 5 - X11
# 6 - reboot (Do NOT set initdefault to this)
#
# id:5:initdefault:
id:3:initdefault:
Now if you reboot your system, you will be greeted with a text based login screen. This allows you to log into your system with a text based session from within a virtual terminal. A text based session usually does not consume as much system resources as would be the case with a graphical session. Then build your Sage source distribution from within your text based session. You need to make sure that you can first restore your graphical session, before you attempt to log into a text based session.
The “malloc” messages you refer to might be something such as the following:
sage -t devel/sage-main/sage/libs/pari/gen.pyx
python(4563) malloc: *** vm_allocate(size=4096000000) failed (error code=3)
python(4563) malloc: *** error: can't allocate region
python(4563) malloc: *** set a breakpoint in szone_error to debug
The issue above is not a doctest failure. It is an error message printed by the system and it is exactly what one expects to see. In that particular doctest, we try to allocate a very large list in Pari that does not fit into physical memory (it is at least 100GB in size). So Mac OS X tells you that it could not allocate a chunk of memory roughly 4 GB in size, which is expected, if you are using Sage on a 32-bit version of OS X and you have compiled Sage in 32-bit bit mode or your binary Sage distribution is 32-bit.
The most likely cause is enabled power management. Disabling it should fix the problem. Depending on your flavor of distribution, this might either be possible with some nice GUI tool or not. On the command line do the following as root for each CPU you have:
/usr/bin/cpufreq-selector -g performance -c #number CPU
On Ubuntu, try disabling “Power Manager” via
System --> Preferences --> Sessions
under the “Startup Programs” or using cpufreq-set via the command line.
The problem is related to SELinux. See this page for some tips to fix this: http://www.ittvis.com/services/techtip.asp?ttid=3092. We are currently tracking this issue at ticket #480.
The problem can be fixed by running the following command:
chcon -t textrel_shlib_t /path/to/libpari-gmp.so.2
Try doing hg_scripts.merge(), followed by hg_scripts.commit(). Run both of these commands from the Sage command line. As an alternative, you can simply try hg_scripts.pull().
We currently do not have a ready-to-go solution. There are several possibilities. Use screen, nohup or disown. We are tracking the issue at ticket #381 so stay tuned.
See http://www.math.union.edu/~dpvc/jsMath/download/jsMath-fonts.html where it says:
For Mac OS X users: download and unpack the archive, then drag
the fonts to your Library/Fonts folder (or to the FontBook, or
just double-click them and press the "install" button).
Since Sage 2.9.2, we have switched to using Jmol, a Java applet, for 3-D plotting. There are several possibilities for the cause of the malfunction. You do not have Java installed at all or the Java installed is an older GNU based alternative Java implementation, which causes some yet to determine problem. A solution to both issues is to either install Sun’s Java SDK or to update the GNU based Java implementation. As of January 2008 Debian’s Java in testing works, but stable does have problems.
If you are running a brand new (as of April 2008) Ubuntu 8.04, they ship the Java Plugin by IcedTea. This is basically a good idea, but a bit too early since it is broken. Either wait for an update or uninstall the IcedTea Plugin and install the “SUN Java 6 Plugin”. Later, switch back to IcedTea, since it is based on OpenJDK 7 (or SUNs Java 7) which is the next Java version. You can check for the used plugin in Firefox 3 by typing “about:plugins” into the URL bar. Read more about this issue at launchpad.
Yes! Absolutely! Basically the only constraint is that if you make changes to Sage itself and redistribute this changed version of Sage publicly, then you must make these changes available to us so that we can put them into the standard version of Sage (if we want). Otherwise, you are free to use as many copies of Sage as you want completely for free to make money, etc. without paying any license fees at all.
You need to give hints to Sage so that it uses C++ (both Givaro and NTL are C++ libraries), and it also needs the GMP and STDC C++ libraries. Here is a small example:
# These comments are hints to Sage/Pyrex about the compiler and
# libraries needed for the Givaro library:
#
#clang c++
#clib givaro gmpxx gmp m stdc++
cimport sage.rings.finite_field_givaro
# Construct a finite field of order 11.
cdef sage.rings.finite_field_givaro.FiniteField_givaro K
K = sage.rings.finite_field_givaro.FiniteField_givaro(11)
print "K is a", type(K)
print "K cardinality =", K.cardinality()
# Construct two values in the field:
cdef sage.rings.finite_field_givaro.FiniteField_givaroElement x
cdef sage.rings.finite_field_givaro.FiniteField_givaroElement y
x = K(3)
y = K(6)
print "x is a", type(x)
print "x =", x
print "y =", y
print "x has multiplicative order =", x.multiplicative_order()
print "y has multiplicative order =", y.multiplicative_order()
print "x*y =", x*y
# Show that x behaves like a finite field element:
for i in range(1, x.multiplicative_order() + 1):
print i, x**i
assert x*(1/x) == K.one_element()
To find out more, type
sage.rings.finite_field_givaro.FiniteField_givaro.
at the Sage prompt and hit tab, then use ?? to get more information on each function. For example:
sage.rings.finite_field_givaro.FiniteField_givaro.one_element??
tells you more about the multiplicative unit element in the finite field.
Search the build log (install.log) to see if you are getting the following log message:
fork: Resource temporarily unavailable.
If so, try the following. Create (or edit) /etc/launchd.conf and include the following:
limit maxproc 512 2048
then reboot. See this page for more details.
Define two variables and then evaluate as follows:
sage: a = 5; b = 8
sage: a.__xor__(b), 13
(13, 13)
You can also do
sage: (5).__xor__(8)
13
The parentheses are necessary so that Sage does not think you have a real number. There are several ways to define a function:
sage: xor = lambda x, y: x.__xor__(y)
sage: xor(3, 8)
11
Another option, which sneaks around the Sage preparser, is
sage: def xor(a, b):
... return eval("%s^%s" % (a, b))
...
sage: xor(3, 8)
11
You can also turn off the Sage preparser with preparser(False), then ^ will work just like in Python. You can later turn on the preparser with preparser(True). That only works in command line Sage. In a notebook, switch to Python mode.
The general—but perhaps not very helpful—answer is that you need to install fullpage.sty into a directory searched by TeX. On Ubuntu (and probably many other Linux distributions), you should install the texlive-latex-extra package. If that is not available, try installing the tetex-extra package. If you are using Mac OS X, you will have to use whatever TeX distribution you use to get fullpage.sty (if you use MacTeX, it is likely already installed). If you are using the VirtualBox image on Windows, you will need to log into the VirtualBox image and install texlive-latex-extra there.
It is because of how functions are defined in Sage with the f(x) = expr notation using the preparser. Also notice that if you make this mistake inside of an if statement, you will get a SyntaxError before anything else goes wrong. So in this case, there is no problem.