[sage-devel] new talk: The Development of Symbolic Calculus in Sage
http://wstein.org/talks/stein-sd24/stein-sd24.pdf -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] sage is getting big
Here are some stats about "lines in the sage library" of Sage-4.5: cd SAGE_ROOT/devel/sage/sage/ - There are 659 Cython files in Sage: flat:sage wstein$ find . -print |grep "pyx\|pxi\|pxd" |wc -l 659 - There are XX Cython modules in Sage flat:sage wstein$ grep Extension ../module_list.py |wc -l 283 - There are XX lines of Cython files flat:sage wstein$ find . -print |grep "pyx\|pxi\|pxd" | xargs cat |wc -l 313548 - There are XX unique lines of Cython files flat:sage wstein$ find . -print |grep "pyx\|pxi\|pxd" | xargs cat |sort|uniq|wc -l 150991 We (=Craig Citro and Gonzalo Tornaria) wrote a sophisticated dependency checker just for Sage, so that if you modify one of these 659 Cython files, then type "sage -br", exactly the right cython files are rebuilt. Also, we have a parallel build system, so if you do export MAKE="make -j8" sage -b then 8 cython files will be compiled in parallel. - There are 1192 Python files in Sage: flat:sage wstein$ find . -print |grep ".py$" |wc -l 1192 - There are XX lines of Cython files flat:sage wstein$ find . -print |grep ".py$" | xargs cat | wc -l 635164 - There are XX unique lines of Cython files flat:sage wstein$ find . -print |grep ".py$" | xargs cat | sort|uniq |wc -l 309430 Yeah... the Sage library is pretty daunting: flat:sage wstein$ find . -print |grep "pyx\|pxi\|pxd\|.py$" | xargs cat |wc -l 948712 flat:sage wstein$ find . -print |grep "pyx\|pxi\|pxd\|.py$" | xargs cat |sort|uniq|wc -l 453612 -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] ATLAS - proposal to allow a threaded build.
> How does this sound. > > 1) We add an environment variable SAGE_ATLAS_THREADS > 2) If unset, then the behavior is unchanged, so we build an unthreaded > ATLAS. 3) If set to "auto": > > $ export SAGE_ATLAS_THREADS=auto > > then we let ATLAS automatically determine the number of threads. (I think > that is what ATLAS determines as the number of processors on your system. > IIRC, on 't2.math' this was 128). > > 4) If set to an integer N, > > $ export SAGE_ATLAS_THREADS=8 > > we use N (in this case 8) threads. Hi, somehow I get the feeling the number of environment variables in Sage is increasing on an exponential rate. I'd much rather not have some ATLAS specific environment variable. Instead - if we need a variable - I'd have SAGE_NUM_CORES or something. William convinced me the other day that it would be better to build with multicore support by default (since that's the future anyway) instead of only if some obscure variable is set. I'm sure this would require more work but might be a worthwhile activity. Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99 _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF _www: http://www.informatik.uni-bremen.de/~malb _jab: martinralbre...@jabber.ccc.de -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Import problems
On Fri, Jul 16, 2010 at 8:21 PM, koffie wrote: > Dear All, > > I was writing some code for sage and ran into trouble. The code was > working just fine when it was a standalone function. Then I tried to > add it to a pyx file (sage/rings/fraction_field_element.pyx to be > precise) and ran into trouble. Somewhere in the code I would like to > use the command PolynomialRing, so I had to import it for else it > wouldn't build. So I added the line > > from sage.rings.polynomial.polynomial_ring_constructor import > PolynomialRing > > to the file. After having done this sage will build, but when running > sage I get into trouble. I have no idea about how importing and stuff > works in python/cython so if someone could help me with this I would > be very glad. It looks like you've got a problem with a circular import, where file A imports file B, which imports file C, ..., which imports file A. I don't know of a simple, systematic, efficient way to solve such problems. The easy way is to move this line: from sage.rings.polynomial.polynomial_ring_constructor import PolynomialRing inside the function you just added. (For example, just put it on the line before you use PolynomialRing.) The only problem with this solution is that it adds a tiny bit of time (maybe a few microseconds) to your function. If your function is very time-critical, you should find another solution; but otherwise this should work fine. Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] About mpmath and sympy
> As an aside, if two upstream packages include another upstream > package (e.g. both include GMP) what does Sage do? Are there > two copies of GMP? They could have different versions of the > same package since project 1 could have stopped at one version > and project 2 could have stopped at another. Sage could be > using a third. Funny you mentioned GMP. At one point givaro was shipping its own GMP. It was actually an accident on the givaro devs part - and I had notified them. But I didn't notify this list. So in at least one release givaro was actually overwriting part of GMP. For your question I guess it depends if it is kept internally without clash with anything else or it actively tries to overwrite things that have been installed already. The second one is a no-no, and the first one should be fixed to use upstream but not as a matter of emergency I would guess. Francois -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Import problems
Dear All,
I was writing some code for sage and ran into trouble. The code was
working just fine when it was a standalone function. Then I tried to
add it to a pyx file (sage/rings/fraction_field_element.pyx to be
precise) and ran into trouble. Somewhere in the code I would like to
use the command PolynomialRing, so I had to import it for else it
wouldn't build. So I added the line
from sage.rings.polynomial.polynomial_ring_constructor import
PolynomialRing
to the file. After having done this sage will build, but when running
sage I get into trouble. I have no idea about how importing and stuff
works in python/cython so if someone could help me with this I would
be very glad.
Below you will find the trouble I run in to when starting sage:
--
| Sage Version 4.4.4, Release Date: 2010-06-23 |
| Type notebook() for the GUI, and license() for information.|
--
ERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
The error message is: ('EOF in multi-line statement', (69, 0))
---
ImportError Traceback (most recent call
last)
/Applications/sage/local/lib/python2.6/site-packages/IPython/
ipmaker.pyc in force_import(modname)
64 reload(sys.modules[modname])
65 else:
---> 66 __import__(modname)
67
68
/Applications/sage/local/bin/ipy_profile_sage.py in ()
5 preparser(True)
6
> 7 import sage.all_cmdline
8 sage.all_cmdline._init_cmdline(globals())
9
/Applications/sage/local/lib/python2.6/site-packages/sage/
all_cmdline.py in ()
12 try:
13
---> 14 from sage.all import *
15 from sage.calculus.predefined import x
16 preparser(on=True)
/Applications/sage/local/lib/python2.6/site-packages/sage/all.py in
()
62 get_sigs()
63
---> 64 from sage.misc.all import * # takes a while
65
66 from sage.misc.sh import sh
/Applications/sage/local/lib/python2.6/site-packages/sage/misc/all.py
in ()
68 from sage_eval import sage_eval, sageobj
69
---> 70 from sage_input import sage_input
71
72 from cython import cython_lambda, cython_create_local_so
/Applications/sage/local/lib/python2.6/site-packages/sage/misc/
sage_input.py in ()
161 """
162
--> 163 from sage.misc.functional import parent
164 import math
165
/Applications/sage/local/lib/python2.6/site-packages/sage/misc/
functional.py in ()
36
37
---> 38 from sage.rings.complex_double import CDF
39 from sage.rings.real_double import RDF, RealDoubleElement
40
/Applications/sage/local/bin/complex_double.pyx in init
sage.rings.complex_double (sage/rings/complex_double.c:14319)()
/Applications/sage/local/lib/python2.6/site-packages/sage/rings/
complex_field.pyc in ComplexField(prec, names)
84 if not C is None:
85 return C
---> 86 C = ComplexField_class(prec)
87 cache[prec] = weakref.ref(C)
88 return C
/Applications/sage/local/lib/python2.6/site-packages/sage/rings/
complex_field.pyc in __init__(self, prec)
184 ParentWithGens.__init__(self, self._real_field(),
('I',), False, category = Fields())
185 #self._populate_coercion_lists_()
--> 186
self._populate_coercion_lists_(coerce_list=[complex_number.RRtoCC(self._real_field(),
self)])
187
188 def __reduce__(self):
/Applications/sage/local/lib/python2.6/site-packages/sage/rings/
complex_number.so in sage.rings.complex_number.RRtoCC.__init__ (sage/
rings/complex_number.c:13971)()
/Applications/sage/local/lib/python2.6/site-packages/sage/categories/
map.so in sage.categories.map.Map.__init__ (sage/categories/map.c:1951)
()
/Applications/sage/local/lib/python2.6/site-packages/sage/categories/
homset.pyc in Hom(X, Y, category)
150 # For the moment, this is the category, for compatibility
with the current implementations
151 # of Homset in rings, schemes, ...
--> 152 H = category.hom_category().parent_class(X, Y, category =
category)
153
154 ##_cache[key] = weakref.ref(H)
/Applications/sage/local/lib/python2.6/site-packages/sage/categories/
rings.pyc in __new__(cls, X, Y, category)
115
116 """
--> 117 from sage.rings.homset import RingHomset
118 return RingHomset(X, Y, category = category)
119
/Applications/sage/local/lib/python2.6/site-packages/sage/rings/
homset.pyc in ()
15
16 import morphism
---> 17 import quotient_ring
18
19 def is_RingHomset(H):
/Applications/sage/local/lib/python2.6/site-packages/sage/rings/
quotient_ring.pyc in ()
30 import commutative_ring
31 import ideal
-
Re: [sage-devel] About mpmath and sympy
As an aside, if two upstream packages include another upstream package (e.g. both include GMP) what does Sage do? Are there two copies of GMP? They could have different versions of the same package since project 1 could have stopped at one version and project 2 could have stopped at another. Sage could be using a third. François Bissey wrote: Hi, Newer sympy has a bundled copy of mpmath, what causes several problems in my sagemath package. I was in vacation during most of Mandriva 2010.1 freeze, and did not fully test the package for some time, but I am working on an update for it; basically an 's/import mpmath/import sympy.mpmath as mpmath/', but would like to know what would be the better approach. (just letting the code use both leads to SEGvs). The new sagemath package will conflict with python-mpmath-0.14-1mdv2010.1 (forcing it to be uninstalled), because the sympy is python-sympy-0.6.7-1mdv2010.1. Hi Paulo, that will probably be a pain for us in gentoo as well. At the moment we are sticking with sympy-0.6.6 as sympy-0.6.7 gives us trouble. The gentoo philosophy at this point will be to remove mpmath from sympy and make it a requirement. But I haven't been actively working on that. Francois -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] About mpmath and sympy
2010/7/16 François Bissey : >> Hi, >> >> Newer sympy has a bundled copy of mpmath, what causes several >> problems in my sagemath package. I was in vacation during most of >> Mandriva 2010.1 freeze, and did not fully test the package for some >> time, but I am working on an update for it; basically an 's/import >> mpmath/import sympy.mpmath as mpmath/', but would like to know what >> would be the better approach. (just letting the code use both leads to >> SEGvs). >> >> The new sagemath package will conflict with >> python-mpmath-0.14-1mdv2010.1 (forcing it to be uninstalled), because >> the sympy is python-sympy-0.6.7-1mdv2010.1. >> > Hi Paulo, > > that will probably be a pain for us in gentoo as well. > At the moment we are sticking with sympy-0.6.6 as > sympy-0.6.7 gives us trouble. The gentoo philosophy > at this point will be to remove mpmath from sympy and > make it a requirement. But I haven't been actively working > on that. Hi François, I think the proper solution should be for upstream sympy to not have a copy of mpmath, or, somehow not let it conflict with a toplevel mpmath. Otherwise, patching will be required. For now I am using this one (with minor changes for 2010.1 and sage 4.4): http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/sagemath/current/SOURCES/sage-4.4.4-sympy_mpmath.patch?view=markup and forcing python-mpmath to be uninstalled if upgrading the sagemath package. > Francois > > -- Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] ATLAS - proposal to allow a threaded build.
On Fri, Jul 16, 2010 at 4:34 PM, Dr. David Kirkby wrote: > How does this sound. > > 1) We add an environment variable SAGE_ATLAS_THREADS > 2) If unset, then the behavior is unchanged, so we build an unthreaded > ATLAS. > 3) If set to "auto": > > $ export SAGE_ATLAS_THREADS=auto > > then we let ATLAS automatically determine the number of threads. (I think > that is what ATLAS determines as the number of processors on your system. > IIRC, on 't2.math' this was 128). > > 4) If set to an integer N, > > $ export SAGE_ATLAS_THREADS=8 > > we use N (in this case 8) threads. +1 for this plan. Thanks for looking into this; I'm looking forward to seeing what ATLAS does on my desktop. Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] ATLAS - proposal to allow a threaded build.
Currently, when ATLAS builds in Sage, it uses this option to the configure scrip, it used the option -t 0, which disables threading. The comment in spkg-install-script says: # -t 0: disable threading for now. and we can see that actually happens. ../src/configure --prefix="$SAGE_LOCAL" --with-netlib-lapack="$SAGE_LOCAL"/lib/liblapack.a \ -Si cputhrchk 0 -Fa alg -fPIC -t 0 -C if $FCOMPILER -b $bitwidth $SIMD_FLAGS How does this sound. 1) We add an environment variable SAGE_ATLAS_THREADS 2) If unset, then the behavior is unchanged, so we build an unthreaded ATLAS. 3) If set to "auto": $ export SAGE_ATLAS_THREADS=auto then we let ATLAS automatically determine the number of threads. (I think that is what ATLAS determines as the number of processors on your system. IIRC, on 't2.math' this was 128). 4) If set to an integer N, $ export SAGE_ATLAS_THREADS=8 we use N (in this case 8) threads. Does that sounds more logical than only letting an threaded ATLAS be built? Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] About mpmath and sympy
> Hi, > > Newer sympy has a bundled copy of mpmath, what causes several > problems in my sagemath package. I was in vacation during most of > Mandriva 2010.1 freeze, and did not fully test the package for some > time, but I am working on an update for it; basically an 's/import > mpmath/import sympy.mpmath as mpmath/', but would like to know what > would be the better approach. (just letting the code use both leads to > SEGvs). > > The new sagemath package will conflict with > python-mpmath-0.14-1mdv2010.1 (forcing it to be uninstalled), because > the sympy is python-sympy-0.6.7-1mdv2010.1. > Hi Paulo, that will probably be a pain for us in gentoo as well. At the moment we are sticking with sympy-0.6.6 as sympy-0.6.7 gives us trouble. The gentoo philosophy at this point will be to remove mpmath from sympy and make it a requirement. But I haven't been actively working on that. Francois -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: undo function in notebook stuffed entirely
I can confirm that in 4.4.4 ALL revisions (there were 11, including some from '1 day ago') of a worksheet I am working on are identical to the current revision, which they definitely should not be! This isn't exactly the same as Stan's issue, but almost certainly related. Stan, can you post which ticket is related to this (you mention one below)? I agree that this is very bad. I am pretty sure there was a time where the 'wasted space' was fixed but this didn't happen, but that may have been before the switch to the sagenb package. - kcrisman On Jul 16, 10:38 am, Stan Schymanski wrote: > Dear all, > > There has been a post in April about problems with the undo function > in the notebook and a ticket was created, but I have to report that > the undo function is stuffed entirely both in sage 4.4.3 and 4.4.4. > I just saved and closed a worksheet that was misbehaving and when I re- > opened it, it was in the version of ages ago and the undo list is > empty. The undo list is actually empty for the other notebooks as > well, so I haven't only lost a day of work but I may be losing more. > Is there a way to use the old notebook again, where it was working > well, despite "wasting space"? This is a major regression in my eyes. > > Thanks for your help! > > Cheers, > Stan -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] About mpmath and sympy
Hi, Newer sympy has a bundled copy of mpmath, what causes several problems in my sagemath package. I was in vacation during most of Mandriva 2010.1 freeze, and did not fully test the package for some time, but I am working on an update for it; basically an 's/import mpmath/import sympy.mpmath as mpmath/', but would like to know what would be the better approach. (just letting the code use both leads to SEGvs). The new sagemath package will conflict with python-mpmath-0.14-1mdv2010.1 (forcing it to be uninstalled), because the sympy is python-sympy-0.6.7-1mdv2010.1. Thanks, Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Fwd: Re: [R] Mathematica and R
Thanks! I replied to this in at least a preliminary way. But he is right that the easy-to-find documentation on many of the interfaces in practical terms is pretty rudimentary. - kcrisman On Jul 16, 3:12 pm, "Dr. David Kirkby" wrote: > I happened to notice this on r-help. > > Dave > > > > Original Message > Subject: Re: [R] Mathematica and R > Date: Fri, 16 Jul 2010 13:48:49 -0400 > From: David Bickel > To: r-h...@r-project.org > > Hi Albyn, > > Thank you very much for the suggestion. > > I managed to install Sage on Windows (via a Linux VM), but I cannot find > any documentation on how to use R from Sage. Maybe I should use the web > interface of Sage to avoid having to install R on the VM. > > Best regards, > David > > On 10-07-14 10:24, Albyn Jones wrote: > > Take a look at Sage, which is an open source alternative. It already > > integrates R (http://www.sagemath.org) > -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Fwd: Re: [R] Mathematica and R
I happened to notice this on r-help. Dave Original Message Subject: Re: [R] Mathematica and R Date: Fri, 16 Jul 2010 13:48:49 -0400 From: David Bickel To: r-h...@r-project.org Hi Albyn, Thank you very much for the suggestion. I managed to install Sage on Windows (via a Linux VM), but I cannot find any documentation on how to use R from Sage. Maybe I should use the web interface of Sage to avoid having to install R on the VM. Best regards, David On 10-07-14 10:24, Albyn Jones wrote: Take a look at Sage, which is an open source alternative. It already integrates R (http://www.sagemath.org) albyn Quoting David Bickel : What are some effective ways to leverage the strengths of R and Mathematica for the analysis of a single data set? More specifically, are there any functions that can assist with any of the following? 1. Calling an R function from Mathematica. 2. Calling a Mathematica function from R. 3. Using XML or another reliable data format to pass vectors, matrices, and/or lists from one environment to the other. Any advice would be appreciated. David -- David R. Bickel, PhD Associate Professor Ottawa Institute of Systems Biology Biochem., Micro. and I. Department Mathematics and Statistics Department University of Ottawa 451 Smyth Road Ottawa, Ontario K1H 8M5 http://www.statomics.com Office Tel: (613) 562-5800 ext. 8670 Office Fax: (613) 562-5185 __ r-h...@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. __ r-h...@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: cephes is seriously broken
On Fri, Jul 16, 2010 at 3:30 AM, Dr. David Kirkby wrote: > On 07/16/10 10:42 AM, Peter Jeremy wrote: >> >> On 2010-Jul-16 10:48:15 +0200, William Stein wrote: >>> >>> worked". This wouldn't be likely with Microsoft's own compilers... >>> For starters, the Singular developers don't work with those compilers, >>> so the Singular devs will make all kinds of code changes, which would >>> then have to be ported/fixed. >> >> As has been discussed previously, this effort is worthwhile in any >> case. Firstly, gcc does not generate especially good SPARCv9 or iA64 >> code - being able to use vendor compilers is likely to provide a boost >> to Sage performance on those platforms. The vast majority of people, by far, do not use SPARCv9 or iA64, and though we shouldn't abandon support for them I'd say that getting a Windows version up and running at all (which was the point of cephes that started this thread) is vastly more important than optimized code on rare platforms (though for those with different hardware and special compilers, it's probably worth their time to try to make the most of their resources, and we're certainly not throwing up any roadblocks in that direction). >> Secondly, the different checks >> performed by different compilers are likely to turn up in Sage code and >> correcting them will improve the reliability and robustness of Sage. >> > > I agree with this very much. I think William see evidence of how the Sun > compiler (which was being called by mistake), found two serious bugs in > c_lib. > > http://trac.sagemath.org/sage_trac/ticket/6595 > > Unfortunately, so much of the code in Sage is written in a GNU dialect of > C/C++ and not C/C++, that building Sage with native compilers would be very > difficult. Yep. Apparently some coders find value in using the GNU dialects rather than sticking to the standards. (Or it could be in part due to ignorance, much of this code requires a deep math background rather than a deep engineering background to write). This does not negate the value of being able to compile on a variety of compilers, but we take what we're given. Currently, the (huge) problem is that there's no Windows port of Sage, and since most upstreams components have better support for Cygwin than the other Windows options (whether incidentally or by design). Once we have a stable and maintainable Cygwin port those interested can look at porting to other Windows platforms (including the necessary upstream work). - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Should we create a 'reversed' deps file for test purposes?
On Thu, Jul 15, 2010 at 9:55 AM, wrote: > Currently the spkg/standard/deps file has the dependancies for Sage listed > in alphabetical order. I suspect that might mean for serial builds, if there > are no stated dependancies, things build in alphabetical order. > > all: $(BASE) \ > $(INST)/$(ATLAS) \ > $(INST)/$(BLAS) \ > $(INST)/$(BOEHM_GC) \ > $(INST)/$(BOOST_CROPPED) \ > $(INST)/$(CDDLIB) \ > $(INST)/$(CEPHES) \ > > $(INST)/$(TWISTED) \ > $(INST)/$(WEAVE) \ > $(INST)/$(ZLIB) \ > $(INST)/$(ZNPOLY) \ > $(INST)/$(ZODB) > > > If we created a deps file with the dependencies list the other way, we might > be likely to induce a very different build order. That could be useful for > testing purposes, to see if there are hidden depenancies. > > I'm not however sure if my logic is flawed here. I would have thought that > for serial builds, the order would have been dependent on the order they are > listed is the 'deps' file, unless there are stated dependencies which stop > that. That's an interesting idea, and worth trying at least. The actual order for non-dependent packages probably depends on some arbitrary internal format, but that might be influenced by the ordering in the makefile. - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: cephes is seriously broken
there are many major Sage components that do not build natively on Windows, e.g. GAP, and where native ports are not on roadmaps of the corresponding development teams. Other platforms might have a better chance, e.g. GAP is very compiler- tolerant (as there is no C++ there). Dima On Jul 16, 10:42 am, Peter Jeremy wrote: > On 2010-Jul-16 10:48:15 +0200, William Stein wrote: > > >worked". This wouldn't be likely with Microsoft's own compilers... > >For starters, the Singular developers don't work with those compilers, > >so the Singular devs will make all kinds of code changes, which would > >then have to be ported/fixed. > > As has been discussed previously, this effort is worthwhile in any > case. Firstly, gcc does not generate especially good SPARCv9 or iA64 > code - being able to use vendor compilers is likely to provide a boost > to Sage performance on those platforms. Secondly, the different checks > performed by different compilers are likely to turn up in Sage code and > correcting them will improve the reliability and robustness of Sage. > > -- > Peter Jeremy > > application_pgp-signature_part > < 1KViewDownload -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] spkg-check
On 07/16/10 03:03 PM, Sergey Bochkanov wrote: Hello, Dr.. You wrote 16 июля 2010 г., 17:37:25: So if spkg-check is executed, I can be sure that spkg was successfully installed into system? Not exactly, as some packages unfortunately ignore errors, so if the package fails to install, you will not know it. I am talking about my own package, so I know that its author at least tried to handle all errors during install :) Yes, I had not realised you were talking of your own package. If you recall, I looked at that, and found it was ok. The tests passed on a system or two I checked it on. You did have some self-tests, though I remarked the output was only shown at the end, not after each test. You said it was a problem with flusing stdout and it behaved differently on Linux to Solaris. Not all packages have spkg-check files - in fact, the majority do not. A list of the packages which have them missing can be found on this ticket. http://trac.sagemath.org/sage_trac/ticket/9281 Looks like that spkg-check is not very popular way of testing packages. That's true, though there is an interest in improving that situation by a few people at least. If you look at the ticket I created listing the packages which don't have spkg-check files, you will see several others have added their usernames to 'cc' field. John Palmieri has done some work on this http://trac.sagemath.org/sage_trac/ticket/9352 I fixed a couple recently http://trac.sagemath.org/sage_trac/ticket/9277 http://trac.sagemath.org/sage_trac/ticket/9286 http://trac.sagemath.org/sage_trac/ticket/9309 http://trac.sagemath.org/sage_trac/ticket/9308 and have created tickets for fixing a couple more http://trac.sagemath.org/sage_trac/ticket/9311 Many packages rely on doctests. It leads me to the next question. I work on test suite for ALGLIB spkg. Previous release contained only computational core tests, now I want to add Python-C integration tests. These tests will be integrated into spkg-check. So testing will be done as follows: 1) spkg-check is called 2) computational core (external shared library) is tested 3) if failed, testing is stopped 4) communication between core and Python is tested Step (4) is just execution of very large Python script which tries to call different ALGLIB functions and to check their result. This script is automatically generated from formal description - it will allow me to use these tests later in other programming languages. It is also possible to automatically generate doctests from formal description used to generate spkg-check. I'm impressed. Sage needs more people like you, who take testing a bit more seriously. So I have three options: a) to test ALGLIB from spkg-check only b) to generate doctests and to test ALGLIB using doctests only c) to use BOTH spkg-check and doctests But what should I choose in this situation? Many packages are checked by both spkg-check and doctests. If you take a package like R for instance, the spkg-check will run R's testsuite, whereas the doctests will only confirm that R can be called from Sage - there is very little actual testing done of R. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Unreasonable docfails in symbolic/random_tests.py
Thank you!!! Andrey On Thu, Jul 15, 2010 at 10:36 PM, Carl Witty wrote: > On Thu, Jul 15, 2010 at 1:38 PM, Andrey Novoseltsev > wrote: >> Hi Carl, >> >> For example this installation of sage-4.5.alpha1 >> >> novos...@sage:/scratch/novoselt/sage-4.5.alpha1/devel/sage-main$ hg >> qapplied >> trac_9502_basis_parent_bug_in_FreeModule.patch >> trac_9128-sphinx_links_all-fh.patch >> trac_9128-intersphinx_python_database-fh.patch >> trac_9188_fix_facet_normal.patch >> trac_9188_fix_facet_normal_reviewer.patch >> trac_9062_add_support_for_toric_lattices.patch >> trac_9062-cmp_fix.2.patch >> trac_8986_add_support_for_convex_rational_polyhedral_cones.patch >> trac_8986_cmp_fix.patch >> trac_8987_add_support_for_rational_polyhedral_fans.patch >> trac_8987_add_enhanced_cones_and_fans.patch >> trac_8987_review_changes.patch >> trac_8987_repr_changes.patch >> trac_8987_cmp_fix.patch >> trac_8988_add_support_for_toric_varieties.patch >> >> shows two broken doctests in symbolic/random_tests. Moreover, it seems >> that my doctest patch does not fix one of the issues anymore! It will >> be very very good if you could fix this issue, as I have no idea >> what's going on... > > Thanks, that's exactly what I needed to track down the issue. Turns > out it was a bug in random_tests.py. (I was inadvertently depending > on the order of the output of .values() on a dict, which is a Bad > Idea. The question isn't why it broke, it's why did it ever work.) > > There's a patch up at #9514. > > Carl > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] spkg-check
Hello, Dr.. You wrote 16 июля 2010 г., 17:37:25: >> So if spkg-check is executed, I can be sure that spkg was successfully >> installed into system? > Not exactly, as some packages unfortunately ignore errors, so if the package > fails to install, you will not know it. I am talking about my own package, so I know that its author at least tried to handle all errors during install :) > Not all packages have spkg-check files - in fact, the majority do > not. A list of the packages which have them missing can be found on > this ticket. http://trac.sagemath.org/sage_trac/ticket/9281 Looks like that spkg-check is not very popular way of testing packages. Many packages rely on doctests. It leads me to the next question. I work on test suite for ALGLIB spkg. Previous release contained only computational core tests, now I want to add Python-C integration tests. These tests will be integrated into spkg-check. So testing will be done as follows: 1) spkg-check is called 2) computational core (external shared library) is tested 3) if failed, testing is stopped 4) communication between core and Python is tested Step (4) is just execution of very large Python script which tries to call different ALGLIB functions and to check their result. This script is automatically generated from formal description - it will allow me to use these tests later in other programming languages. It is also possible to automatically generate doctests from formal description used to generate spkg-check. So I have three options: a) to test ALGLIB from spkg-check only b) to generate doctests and to test ALGLIB using doctests only c) to use BOTH spkg-check and doctests But what should I choose in this situation? -- With best regards, Sergey mailto:sergey.bochka...@alglib.net -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] spkg-check
On 07/16/10 02:32 PM, Sergey Bochkanov wrote: Hello, William. You wrote 16 июля 2010 г., 17:12:53: I have a question about spkg-check file. When does it executed - after spkg-install call or independently of it? After. So if spkg-check is executed, I can be sure that spkg was successfully installed into system? Not exactly, as some packages unfortunately ignore errors, so if the package fails to install, you will not know it. But in general, if the package does not install, the 'make' process will exit immediately and Sage will stop building. spkg-check will not be run in that case. Not all packages have spkg-check files - in fact, the majority do not. A list of the packages which have them missing can be found on this ticket. http://trac.sagemath.org/sage_trac/ticket/9281 Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] spkg-check
Hello, William. You wrote 16 июля 2010 г., 17:12:53: >> I have a question about spkg-check file. When does it executed - after >> spkg-install call or independently of it? > After. So if spkg-check is executed, I can be sure that spkg was successfully installed into system? -- With best regards, Sergey mailto:sergey.bochka...@alglib.net -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] spkg-check
On Fri, Jul 16, 2010 at 2:39 PM, Sergey Bochkanov wrote: > Hello, > > I have a question about spkg-check file. When does it executed - after > spkg-install call or independently of it? After. > > -- > With best regards, > Sergey mailto:sergey.bochka...@alglib.net > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] spkg-check
On 07/16/10 01:39 PM, Sergey Bochkanov wrote: Hello, I have a question about spkg-check file. When does it executed - after spkg-install call or independently of it? Only if the environment variable SAGE_CHECK is set to "yes". In other words, by default spkg-check does not run. Personally, I feel it would useful if some files were just checked every time, when the time to test them is very small. GLPK was added recently, and on my machine it takes less than 10 s to check it. So I feel that's a very small fraction of the time to build Sage, so it should be checked. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: multivariate polynomial multiplication, division, GCD, factorization
> I'm *REALLY*, really, really confused about which tarball is the > source code for the > latest version of giac. Just to clarify, please send me a direct link > in email here, please. > Should be there http://www-fourier.ujf-grenoble.fr/~parisse/giac/giac_unstable.tgz or there ftp://ftp-fourier.ujf-grenoble.fr/xcas/giac_unstable.tgz with the latest changes. I realize I did not update the http link since 3 months, should be up to date now. On x64, you should run export CXXFLAGS='-O2 -DSMARTPTR64 -D_I386_ ' before calling configure to get the best performances -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: IDE's; science/engineering
On Jul 11, 12:20 pm, William Stein wrote: > 2. Sage at EuroScipy: > > Another thing -- though most talks mention Cython, not one single talk > given about actual engineers/scientists doing work even mentioned Sage > -- and there were over 30 talks. Perhaps there is no penetration at > all of Sage into scientific computing, at least in Europe. Perhaps > this will change in the next few years, given that NSF looks highly > likely to fund this NSF granthttp://wstein.org/grants/compmath09/ > > Sage was only mentioned in the first keynote by Langtangen, in which > he explained that installing Python for his students is very hard. > His personal solution -- force the students to install Ubuntu, either > natively or in a Virtual Machine. Full > stop.http://picasaweb.google.com/wstein/20100710EuroscipyDay1#549240022431... > He made some (funny) jokes about being a dictator. > > I personally disagree with his suggested "solution". Maple, Matlab, > Mathematica do better, and so can we. I'm not sure if he meant it is a good solution, just an adequate solution that works *now*. Here's some reasons Sage wouldn't work for Langtangen (according to his talk): - He mentioned several Python's being around causing a mess as a problem, Sage adds to this problem. When using a clean VirtualBox, there is guaranteed to only be one Python installed and available, which solved his biggest problem. - LD_LIBRARY_PATH means people must either mess big-time with environment variables, or start using "sage -python" and "sage - ipython" (in which case all the examples about using Python from the internet, scripts with shebangs "#!/usr/bin/env python" etc. stops working). I'm NOT saying Sage can or should do anything about it, just commenting on the situation. I personally think Langtangen is much better off with VirtualBox than Sage at the time being. I personally hope David C.'s efforts will lead somewhere where the science/engineering packaging distribution mess is fixed. BTW, the problem one is trying to solve is much more complex than what MATLAB and Mathematica is dealing with -- I fully expect that whatever MATLAB does would break down under the weight of hundreds of special purpose, openly-developed and often-changing packages as well! (I know Ondrej claims the SPKG system is perfect also for engineers, but I see the FEMHub project as a direct contradiction to that -- what if I want a package from both FEMHub and Sage? It doesn't work easily, out of the box *now*.) (I was unsure whether this should go here or sage-flame, but decided on here...I hope this doesn't end up in a long discussion.) Dag Sverre -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] spkg-check
Hello, I have a question about spkg-check file. When does it executed - after spkg-install call or independently of it? -- With best regards, Sergey mailto:sergey.bochka...@alglib.net -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: cephes is seriously broken
On 07/16/10 10:42 AM, Peter Jeremy wrote: On 2010-Jul-16 10:48:15 +0200, William Stein wrote: worked". This wouldn't be likely with Microsoft's own compilers... For starters, the Singular developers don't work with those compilers, so the Singular devs will make all kinds of code changes, which would then have to be ported/fixed. As has been discussed previously, this effort is worthwhile in any case. Firstly, gcc does not generate especially good SPARCv9 or iA64 code - being able to use vendor compilers is likely to provide a boost to Sage performance on those platforms. Secondly, the different checks performed by different compilers are likely to turn up in Sage code and correcting them will improve the reliability and robustness of Sage. I agree with this very much. I think William see evidence of how the Sun compiler (which was being called by mistake), found two serious bugs in c_lib. http://trac.sagemath.org/sage_trac/ticket/6595 Unfortunately, so much of the code in Sage is written in a GNU dialect of C/C++ and not C/C++, that building Sage with native compilers would be very difficult. Even getting the compilers to be called is difficult, as so many bits of Sage ignore $CC, $CXX etc. Here's just a few I can bugs I can quickly find - I rather gave up collecting a list of them, there are just so many http://trac.sagemath.org/sage_trac/ticket/7074 http://trac.sagemath.org/sage_trac/ticket/7073 http://trac.sagemath.org/sage_trac/ticket/7072 http://trac.sagemath.org/sage_trac/ticket/7071 http://trac.sagemath.org/sage_trac/ticket/7069 http://trac.sagemath.org/sage_trac/ticket/7068 http://trac.sagemath.org/sage_trac/ticket/7066 http://trac.sagemath.org/sage_trac/ticket/7065 http://trac.sagemath.org/sage_trac/ticket/7062 # Probably fixed now, as the ECL developer is very good and I reported this. http://trac.sagemath.org/sage_trac/ticket/7048 http://trac.sagemath.org/sage_trac/ticket/7047 http://trac.sagemath.org/sage_trac/ticket/7044 http://trac.sagemath.org/sage_trac/ticket/7043 http://trac.sagemath.org/sage_trac/ticket/7039 http://trac.sagemath.org/sage_trac/ticket/7038 http://trac.sagemath.org/sage_trac/ticket/7035 http://trac.sagemath.org/sage_trac/ticket/7031 http://trac.sagemath.org/sage_trac/ticket/7028 http://trac.sagemath.org/sage_trac/ticket/7027 Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: cephes is seriously broken
On 2010-Jul-16 10:48:15 +0200, William Stein wrote: >worked". This wouldn't be likely with Microsoft's own compilers... >For starters, the Singular developers don't work with those compilers, >so the Singular devs will make all kinds of code changes, which would >then have to be ported/fixed. As has been discussed previously, this effort is worthwhile in any case. Firstly, gcc does not generate especially good SPARCv9 or iA64 code - being able to use vendor compilers is likely to provide a boost to Sage performance on those platforms. Secondly, the different checks performed by different compilers are likely to turn up in Sage code and correcting them will improve the reliability and robustness of Sage. -- Peter Jeremy pgpgRHwZaZtOc.pgp Description: PGP signature
[sage-devel] Re: include PyCryptoPlus?
I've opened a ticket at http://trac.sagemath.org/sage_trac/ticket/9515 about creating an optional PyCryptoPlus package. Cheers, Martin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: cephes is seriously broken
On Fri, Jul 16, 2010 at 9:45 AM, Georg S. Weber wrote: > > > On 15 Jul., 14:17, Francesco Biscani wrote: >> [possibly OT] Out of curiosity, what was the rationale for going for >> SAGE on Cygwin instead of MinGW? >> >> Cheers, >> >> Francesco. > > AFAIR, > > only the Cygwin environment is able to provide pty's (pseudo tty's) > under Windows, which are needed for the pexpect interfaces to work. It is technically possible to do something like this in Windows (non Cygwin) using the console API. I had a student do a mock-up of this, and it worked, but wasn't so robust/impressive. > (These interfaces connect the Sage library with the functionality of > e.g. Maxima, GAP, ...) > Cygwin also provides a bash environment, with the ability to fork, > which is rare under Windows. rare = impossible, I think. And yes, this fork capability of cygwin is hugely relevant for Sage. > (MinGW sometimes is accompagnied by MSys > for this purpose, but then, MSys is a descendant of Cygwin.) > Again, Sage currently depends on this (bash scripts, ...). All the pexpect interfaces use fork to get going, by the way. > And then there is signal handling (Cython _sig_on, _sig_off), where > Cygwin provides nice abstraction layers, so the current mechanisms > used by *nix-ish Sage nicely carry over, resp. no porting efforts are > needed (I think there are two "Windows processes" used for each > "Cygwin process", just to be able to deal with this signalling stuff). > > A "native" Windows port is definitely wanted, and on the roadmap for > Sage. But that's still a long way to go (rework of pexpect interfaces, > etc.) ... A "native" windows port used to be on the roadmap. It's definitely not on my roadmap anymore. Just to give a sense of how I'm happier with the Cygwin version of Sage, yesterday I logged in via ssh to one of my winxp cygwin machines, built the brand new Singular spkg (that Martin Albrecht just posted), then built all the relevant changes to the Sage library needed to use this new version of Singular... and it all "just worked". This wouldn't be likely with Microsoft's own compilers... For starters, the Singular developers don't work with those compilers, so the Singular devs will make all kinds of code changes, which would then have to be ported/fixed. -- William > > > Cheers, > Georg > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Re: [sage-release] Re: sage-4.5.rc1 released
On Thu, Jul 15, 2010 at 10:33 PM, Robert Miller wrote: > resolved, but since I've already got the build going on taurus, I > won't stop it. All tests pass on taurus as well! -- Robert L. Miller http://www.rlmiller.org/ -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: cephes is seriously broken
On 15 Jul., 14:17, Francesco Biscani wrote: > [possibly OT] Out of curiosity, what was the rationale for going for > SAGE on Cygwin instead of MinGW? > > Cheers, > > Francesco. AFAIR, only the Cygwin environment is able to provide pty's (pseudo tty's) under Windows, which are needed for the pexpect interfaces to work. (These interfaces connect the Sage library with the functionality of e.g. Maxima, GAP, ...) Cygwin also provides a bash environment, with the ability to fork, which is rare under Windows. (MinGW sometimes is accompagnied by MSys for this purpose, but then, MSys is a descendant of Cygwin.) Again, Sage currently depends on this (bash scripts, ...). And then there is signal handling (Cython _sig_on, _sig_off), where Cygwin provides nice abstraction layers, so the current mechanisms used by *nix-ish Sage nicely carry over, resp. no porting efforts are needed (I think there are two "Windows processes" used for each "Cygwin process", just to be able to deal with this signalling stuff). A "native" Windows port is definitely wanted, and on the roadmap for Sage. But that's still a long way to go (rework of pexpect interfaces, etc.) ... Cheers, Georg -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
