[sage-devel] Re: sage-2.8
On Aug 13, 7:00 am, William Stein [EMAIL PROTECTED] wrote: Hi, Hello, I've released sage-2.8. Get it now athttp://sagemath.org/or do sage -upgrade. (Binaries will appear in the near future.) This is a fairly nontrivial upgrade, mainly because it includes a major new version of Singular, and updates to Linbox. There's also new graph theory-related code that came out of the summer REU at Washington and optimizations to mwrank. If you wrote something, sent me a patch, and it isn't in here, definitely send me an email with a new version of the patch. Thanks to the many many people who contributed to this release, including M Abshoff, M Albrecht, C Citro, C Pernet, D Kohel, G Nebe, D Joyner, E Kirkman, R Miller, S Howe, J Mohler, B moretti, J. Rivas, and anybody else who I didn't mention explicitly. NOTE: GCC-4.2 support isn't quite there yet, though we're very close (M Abshoff did build SAGE under GCC-4.2, but there are some issues). Those issues are not due to gcc 4.2, but to odd things happening with certain packages when you have an older gmp installed in /usr/lib. In that case the tests in the mpfi package fail with a link error: ../src/libmpfi.a(mpfi_io.o): In function `mpfi_inp_str': mpfi_io.c:(.text+0x821): undefined reference to `__gmp_get_memory_functions' mpfi_io.c:(.text+0x8d4): undefined reference to `__gmp_get_memory_functions' mpfi_io.c:(.text+0x93b): undefined reference to `__gmp_get_memory_functions' Because the tests just link against a gmp, i.e. -lgmp without specifying a path. Since SAGE compiles against 4.2.1 (with patches) the linker fails against for example 4.1.4. I did build 2.8 and all tests pass on Linux x86-64 with gcc 4.2.0. Cheers, Michael We'll try for GCC-4.2 support in SAGE-2.8.1. Sun Aug 12 18:22:22 2007 2.8: * m albrecht: upgrade to singular-3-0-3 (this was nontrivial) * m albrecht, c pernet: new version of givaro that fixes some bugs. (gcc-4.2 support) * m abshoff, c pernet, w stein: new version of linbox that fixes some bugs. (gcc-4.2 support) * d kohel, g nebe, et al.: Genus computation for quadratic forms (not really made public yet but it is there in quadratic_forms/genus). * e kirkman, r miller: graph database improvements (which are generally useful). * s howe, r miller: bruhat intervals * j mohler: programming guide improvement * b moretti: cayley graphs * juan m bello rivas: fix so clisp can be built in the background. * w stein: upgraded sympy to version 0.5.1, whose main features included much optimization * w stein: implement computing half_integer_weight_modform_basis function for computing a basis for half-integral modular forms of given weight, level, and character. -- William Stein Associate Professor of Mathematics University of Washingtonhttp://www.williamstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: side-by-side comparisons
On Aug 11, 11:46 am, William Stein [EMAIL PROTECTED] wrote: snip/ It would be great if people who are fairly knowledgeable about both SAGE and any of the above systems could add some content. snip/ Hint taken. I'll wait until I have expertise in the same areas of SAGE that I have in Mathematica. Of course, this might take a while, because I am using different parts of each system. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: sage-2.8
Upgrade question: I have been editing two .gp scripts (in data/extcode/pari/simon) and two .py scripts (in devel/sage-main/sage/schemes/elliptic_curves and devel/sage-main/sage/schemes/elliptic_curves) with a view to providing a patch soon. If I do sage -upgrade now will those be overwritten? And in any case should I have been doing this differently than editing those files in place (and running sage -b after each change to test)? Related question: devel/sage-main/sage/schemes/elliptic_curves/ell_rational_field.py is rather long (over 5000 lines); there is a case for splitting it up. Not least because runing sage -t on it takes several minutes, and only a few tests are relevant since most of that file is untouched. John On 8/13/07, William Stein [EMAIL PROTECTED] wrote: Hi, I've released sage-2.8. Get it now at http://sagemath.org/ or do sage -upgrade. (Binaries will appear in the near future.) This is a fairly nontrivial upgrade, mainly because it includes a major new version of Singular, and updates to Linbox. There's also new graph theory-related code that came out of the summer REU at Washington and optimizations to mwrank. If you wrote something, sent me a patch, and it isn't in here, definitely send me an email with a new version of the patch. Thanks to the many many people who contributed to this release, including M Abshoff, M Albrecht, C Citro, C Pernet, D Kohel, G Nebe, D Joyner, E Kirkman, R Miller, S Howe, J Mohler, B moretti, J. Rivas, and anybody else who I didn't mention explicitly. NOTE: GCC-4.2 support isn't quite there yet, though we're very close (M Abshoff did build SAGE under GCC-4.2, but there are some issues). We'll try for GCC-4.2 support in SAGE-2.8.1. Sun Aug 12 18:22:22 2007 2.8: * m albrecht: upgrade to singular-3-0-3 (this was nontrivial) * m albrecht, c pernet: new version of givaro that fixes some bugs. (gcc-4.2 support) * m abshoff, c pernet, w stein: new version of linbox that fixes some bugs. (gcc-4.2 support) * d kohel, g nebe, et al.: Genus computation for quadratic forms (not really made public yet but it is there in quadratic_forms/genus). * e kirkman, r miller: graph database improvements (which are generally useful). * s howe, r miller: bruhat intervals * j mohler: programming guide improvement * b moretti: cayley graphs * juan m bello rivas: fix so clisp can be built in the background. * w stein: upgraded sympy to version 0.5.1, whose main features included much optimization * w stein: implement computing half_integer_weight_modform_basis function for computing a basis for half-integral modular forms of given weight, level, and character. -- William Stein Associate Professor of Mathematics University of Washington http://www.williamstein.org -- John Cremona --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: sage-2.8
Hi
On Sun, Aug 12, 2007 at 10:00:20PM -0700, William Stein wrote:
I've released sage-2.8. Get it now at http://sagemath.org/ or
do sage -upgrade. (Binaries will appear in the near future.)
I run Ubuntu feisty 7.04, up to date from the repositories.
sage2.6 and 2.7 all installed with the same procedure as
shown below and I could connect to the notebook.
tar xvzf /usr/local/src/sage-2.8-i686-Linux.tar.gz
cp sage-2.8-i686-Linux/sage /usr/local/bin/
chmod a+r -R /usr/local/src/sage-2.8-i686-Linux
sed -ie 's#=.#=/usr/local/src/sage-2.8-i686-Linux/#' /usr/local/bin/sage
However in sage-2.8 I get the behaviour below:
$sage
--
| SAGE Version 2.8, Release Date: 2007-08-12 |
| Type notebook() for the GUI, and license() for information.|
--
sage: license()
sage: notebook()
---
type 'exceptions.AttributeError'Traceback (most recent call last)
/var/autofs/misc/home/jan/ipython console in module()
/usr/local/src/sage-2.8-i686-Linux/local/lib/python2.5/site-packages/sage/server/notebook/notebook_object.py
in __call__(self, *args, **kwds)
109
110 def __call__(self, *args, **kwds):
-- 111 return self.notebook(*args, **kwds)
112
113 notebook = run_notebook.notebook_twisted
/usr/local/src/sage-2.8-i686-Linux/local/lib/python2.5/site-packages/sage/server/notebook/run_notebook.py
in notebook_twisted(self, directory, port, address, port_tries, secure, reset,
accounts, server_pool, ulimit, open_viewer)
75 print Login to the SAGE notebook as admin with the
password you specified above.
76 elif nb.user_exists('root') and not nb.user_exists('admin'):
--- 77 s = nb.create_user_with_same_password('admin', 'root')
78
79
/usr/local/src/sage-2.8-i686-Linux/local/lib/python2.5/site-packages/sage/server/notebook/notebook.py
in create_user_with_same_password(self, user, other_user)
146
147 U = self.user(user)
-- 148 passwd = other_user.password()
149 U.set_hashed_password(passwd)
150
type 'exceptions.AttributeError': 'str' object has no attribute 'password'
sage:
regards,
Jan
--
.~.
/V\ Jan Groenewald
/( )\www.aims.ac.za
^^-^^
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
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/
-~--~~~~--~~--~--~---
[sage-devel] Re: sage-2.8
On 8/13/07, Jan Groenewald [EMAIL PROTECTED] wrote:
Hi
On Sun, Aug 12, 2007 at 10:00:20PM -0700, William Stein wrote:
I've released sage-2.8. Get it now at http://sagemath.org/ or
do sage -upgrade. (Binaries will appear in the near future.)
I run Ubuntu feisty 7.04, up to date from the repositories.
sage2.6 and 2.7 all installed with the same procedure as
shown below and I could connect to the notebook.
tar xvzf /usr/local/src/sage-2.8-i686-Linux.tar.gz
cp sage-2.8-i686-Linux/sage /usr/local/bin/
chmod a+r -R /usr/local/src/sage-2.8-i686-Linux
sed -ie 's#=.#=/usr/local/src/sage-2.8-i686-Linux/#'
/usr/local/bin/sage
However in sage-2.8 I get the behaviour below:
$sage
--
| SAGE Version 2.8, Release Date: 2007-08-12 |
| Type notebook() for the GUI, and license() for information.|
--
sage: license()
sage: notebook()
---
type 'exceptions.AttributeError'Traceback (most recent call last)
/var/autofs/misc/home/jan/ipython console in module()
/usr/local/src/sage-2.8-i686-Linux/local/lib/python2.5/site-packages/sage/server/notebook/notebook_object.py
in __call__(self, *args, **kwds)
109
110 def __call__(self, *args, **kwds):
-- 111 return self.notebook(*args, **kwds)
112
113 notebook = run_notebook.notebook_twisted
/usr/local/src/sage-2.8-i686-Linux/local/lib/python2.5/site-packages/sage/server/notebook/run_notebook.py
in notebook_twisted(self, directory, port, address, port_tries, secure,
reset, accounts, server_pool, ulimit, open_viewer)
75 print Login to the SAGE notebook as admin with the
password you specified above.
76 elif nb.user_exists('root') and not nb.user_exists('admin'):
--- 77 s = nb.create_user_with_same_password('admin', 'root')
78
79
/usr/local/src/sage-2.8-i686-Linux/local/lib/python2.5/site-packages/sage/server/notebook/notebook.py
in create_user_with_same_password(self, user, other_user)
146
147 U = self.user(user)
-- 148 passwd = other_user.password()
149 U.set_hashed_password(passwd)
150
type 'exceptions.AttributeError': 'str' object has no attribute 'password'
sage:
Fixes include:
(1) Do
sage: hg_sage.pull()
sage: quit
followed by
# sage -br# from the command line
-- or --
(2) Just try using a different notebook
-- or --
(3) Maybe (I haven't tested this) do
sage: notebook(reset=True)
- William
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
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/
-~--~~~~--~~--~--~---
[sage-devel] Re: Quitting ignored worksheet vs. long computations
I agree. I think a big selling point for sage is using the notebook for teaching. A related thing I would love to have someday is the ability to control which users can see which worksheets, in a fine- grained sense. E.g., I would like to be able to assign students to small groups, and have each group able to see the worksheets of other group members but not the rest of the class, and then after some time let everyone see all the worksheets. The new notebook betas I have seen get at least partway there. On Aug 10, 2:59 pm, Jonathan Bober [EMAIL PROTECTED] wrote: Obviously, this option should not exist on servers that serve a wide range of users. It's really for people doing big computations on their own set of computers. OK. Just a thought - it might be even better to have this option available or not on a per-user basis. In fact, though I haven't used the notebook much, I imagine that it might be nice in general to have a way to assign different privileges to different users. (For example, perhaps user was ought to be able to run a computation on the public notebook on sage.math that is going use 100% load on 8 processors for 3 weeks, whereas user bober, if he exists, shouldn't be able to do that.) --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
[sage-devel] SELinux warnings on sage upgrade
I am running Fedora7 with SELinux in permissive mode, so it will warn me about suspicious activities, but not block them. I am getting warning messages about ldconfig trying to access to files with the default label, default_t. If you have any suggestions how to modify the build scripts to mollify SELinux, I will try them. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: SELinux warnings on sage upgrade
On 8/13/07, Carl Meyer [EMAIL PROTECTED] wrote: I am running Fedora7 with SELinux in permissive mode, so it will warn me about suspicious activities, but not block them. I am getting warning messages about ldconfig trying to access to files with the default label, default_t. If you have any suggestions how to modify the build scripts to mollify SELinux, I will try them. The standard answer with SELinux and SAGE has in the past been it isn't supported at all. If somebody wants to try to support, that would be good and I'd be interested in knowing what is necessary. I think the issue is that until now no SAGE developers use SELinux. William -- William Stein Associate Professor of Mathematics University of Washington http://www.williamstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
[sage-devel] build dependencies
Hi [sage-devel], Burcin PolyBori authors, thanks to Burcin Erocal -- a PhD student from Linz, Austria -- first steps are made to integrate the PolyBori framework into SAGE. PolyBori is a framework for computing in the Boolean Ring F_2[x_1,,x_n]/x_1^2 + x_1, , x_n^2 + x_n using BDDs. More details can be found in http://www.ricam.oeaw.ac.at/mega2007/electronic/26.pdf . Basically, it rocks! PolyBori depends on Scons http://www.scons.org/ as build system and Boost http://www.boost.org/ to link C++ and Python. Both are not required by or shipped with SAGE. My question: What should we do about it? Ship it? Patch PolyBori? Oh, in case you wonder: not integrating PolyBori is not an option for me :-) Any ideas? Thoughts? Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: build dependencies
On Monday 13 August 2007 11:57, Martin Albrecht wrote: Hi [sage-devel], Burcin PolyBori authors, thanks to Burcin Erocal -- a PhD student from Linz, Austria -- first steps are made to integrate the PolyBori framework into SAGE. PolyBori is a framework for computing in the Boolean Ring F_2[x_1,,x_n]/x_1^2 + x_1, , x_n^2 + x_n using BDDs. More details can be found in http://www.ricam.oeaw.ac.at/mega2007/electronic/26.pdf . Basically, it rocks! PolyBori depends on Scons http://www.scons.org/ as build system and Boost http://www.boost.org/ to link C++ and Python. Both are not required by or shipped with SAGE. My question: What should we do about it? Ship it? Patch PolyBori? Oh, in case you wonder: not integrating PolyBori is not an option for me :-) A basic scons can be had in a 228kb tar ball. This is an obvious good idea to install (in my hugely biased opinion). Download the scons-local package (no docs or anything, only what you need to install software using scons). http://www.scons.org/download.php Don't be put off by the pre 1.0 version number. The author of scons is completely anal about stability and backwards compatibility (and evidently totally disagrees with William's philosophy of version numbers :) ). -- Joel --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: quaddouble in sage, and other floating point issues
On Aug 11, 6:03 pm, Jonathan Bober [EMAIL PROTECTED] wrote: I have just noticed that using the C type long double from within sage doesn't work the way that I've expected it to. The issue is a little complicated, and other people on this list probably know more about it than I do, but, briefly, the problem stems from the fact that x86 fpu registers support extended precision (64 bit mantissa), while a C double is just double precision (53 bit mantissa). This causes unexpected results sometimes because floating point arithmetic will be done on the processor at extended precision, and then stored in memory at double precision, which means that that value of a double could theoretically change at any time. This is very bad for packages like quaddouble. It is possible to set the fpu control word so that the fpu only uses double precision, which is one way to solve this problem. Apparently, this is done by default on Windows, but not in Linux (and I have no idea about OS X). One problem with this, however, at least on Linux, is that long doubles no longer 64 bits of precision. It seems that, perhaps accidentally, sage is setting the fpu to use double precision. ... There are a few possible ways to fix this, I think. (1)One way is to rewrite the quaddouble wrapper. Then the fpu control word would need to be saved, set, and reset every time arithmetic was done on a quad double (not a good thing, probably). (2)Another possibility is to decide that it is a good idea to set the fpu to just use double precision, and to make sure that no sage libraries ever expect extended precision. This might actually be the only really cross platform solution that isn't lots of work -- I'm not sure how long doubles will work on Windows or on OS X. Note that the transcendental functions (trigonometric, etc.) in libm on my Debian Linux box are much more accurate if the fpu is in extended precision mode than if the fpu is in double precision mode. (If you're using RDF floating-point numbers in SAGE, then SAGE will use the gsl_ routines instead of the libm routines. I don't know what the effect of extended precision is on the gsl_ routines. If you're using RealField floating-point numbers, then SAGE uses the mpfr routines, and the fpu is not used at all.) (3a)What I think might be the best idea, at least on Linux, is to change the compilation settings for quad double so that the fpu fix is not needed. There are two ways to do this: If a processor supports sse2, then passing gcc -march=whatever -msse2 -mfpmath=sse (maybe the -march isn't needed) will cause gcc to use sse registers and instructions for doubles, and these have the proper precision. In fact, gcc already does this by default for x86-64 cpus, so the quad double package doesn't even need the fpu fix on those architectures. Also, this has the added benefit of being faster. Yes, this certainly sounds like a good idea. In fact, most of SAGE should be built this way whenever possible. (This might mean having two different binary downloads for x86 Linux, though.) Do people use pre-SSE2 x86 processors to run SAGE? (According to http://en.wikipedia.org/wiki/SSE2, Intel added SSE2 with the Pentium 4 in 2001, and AMD added SSE2 with their 64-bit processors in 2003.) (3b)For processors that don't support sse2, gcc can be passed the -ffloat-store option, which fixes the problem by storing doubles in memory after every operation, ensuring that they are always correctly rounded to double precision. This slows things down a little bit, but would probably be much simpler than option (1). Unfortunately this doesn't work. The float-store option rounds all numbers to double precision, avoiding the problem where a number invisibly changes in the middle of a computation; but it does not correctly round to double precision, so it is not usable for quad double. Personally, I think that I like options 3a and 3b. These would probably require rewriting the configure script for quad double. I don't know how to do that, but it probably isn't that hard. Option 2 might be better, though, depending on how Windows (I know sage doesn't work on Windows now, but it would be best not to make it any harder to port to Windows in the future -- also, I'm not whether this effects vmware) and OS X work. Hopefully other people on this list know more about floating point arithmetic issues than I do. I've got my own code that needs to use double precision floating point on x86 in SAGE (my real root isolation routines, which I am still planning to contribute to SAGE soon); so I hope whatever solution we come up with isn't specialized to only work with the quad double package. Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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:
[sage-devel] Re: build dependencies
On Aug 13, 6:43 pm, Joel B. Mohler [EMAIL PROTECTED] wrote: On Monday 13 August 2007 11:57, Martin Albrecht wrote: Hi [sage-devel], Burcin PolyBori authors, thanks to Burcin Erocal -- a PhD student from Linz, Austria -- first steps are made to integrate the PolyBori framework into SAGE. PolyBori is a framework for computing in the Boolean Ring F_2[x_1,,x_n]/x_1^2 + x_1, , x_n^2 + x_n using BDDs. More details can be found in http://www.ricam.oeaw.ac.at/mega2007/electronic/26.pdf . Basically, it rocks! PolyBori depends on Scons Definitely, I saw the Demo and talked with Michael Brickenstein and Alexander Dreyer - very impressive and it would be great to get it intergrated into SAGE. http://www.scons.org/ as build system and Boost http://www.boost.org/ While Scons is rather lightweight Boost is a 17MB compressed tarball. Does PolyBori ship its own copy or do they depend on an external one? If it were an internal copy do they use all of boost or do they just copy the bits they need? When I talked to the authors of the software at MEGA they had stated that they will do a public release by the end of the year. Is that still the case because I looked for the sources a couple minutes ago and counldn't find them. to link C++ and Python. Both are not required by or shipped with SAGE. My question: What should we do about it? Ship it? Patch PolyBori? Oh, in case you wonder: not integrating PolyBori is not an option for me :-) A basic scons can be had in a 228kb tar ball. This is an obvious good idea to install (in my hugely biased opinion). Download the scons-local package (no docs or anything, only what you need to install software using scons).http://www.scons.org/download.php Don't be put off by the pre 1.0 version number. The author of scons is completely anal about stability and backwards compatibility (and evidently totally disagrees with William's philosophy of version numbers :) ). -- Joel Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
[sage-devel] file system slowdown on sage.math
Hello, I tried rsyncing htdocs to my mirror today and the file system on sage.math is very slow (hours+ to rsync a 120MB file and still waiting on that one). One oddity I came across is this one process: rlmill8598 1.5 0.0 3852 512 pts/16 DN+ 09:53 4:09 rm - rf tmp The DN+ indicates Uninterruptible sleep (usually IO) and low priority. According to top the load on sage.math is around 25, but I don't see any process doing a lot of IO. The number of page faults at the moment is miniscule. The is also one zombie at the moment. Any ideas? Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: backup
On 8/13/07, John Cremona [EMAIL PROTECTED] wrote: I had better take a look at the hg documentation, though I did what you suggested and it worked fine for both the .py files (I am used to cvs commit and it looks similar). I did not know that I could do a commit without being officially authenticated, so I assume that the changes I made locally are _not_ thereby part of the SAGE distribution yet. And the hg command did not do anything to the .gp files I had changed. Yes, all the changes you made and the commits are *entirely* local. That's the beauty of distributed source control systems -- you can work on whatever you want, commit whenever you want, and what you're doing in no way messes up what other people are working on. When you have something stable and ready to share, you create a patch bundle and make that available. Anybody else can then easily merge in your patch bundle. It's really much much different than svn or cvs. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: file system slowdown on sage.math
On 8/13/07, mabshoff [EMAIL PROTECTED] wrote: I tried rsyncing htdocs to my mirror today and the file system on sage.math is very slow (hours+ to rsync a 120MB file and still waiting on that one). One oddity I came across is this one process: rlmill8598 1.5 0.0 3852 512 pts/16 DN+ 09:53 4:09 rm - rf tmp The DN+ indicates Uninterruptible sleep (usually IO) and low priority. According to top the load on sage.math is around 25, but I don't see any process doing a lot of IO. The number of page faults at the moment is miniscule. The is also one zombie at the moment. Any ideas? Robert Miller was cleaning up his home directories (we ran out of disk space yesterday) and ... 8598 pts/16 DN+7:47 rm -rf tmp The problem is that the directory tmp contains almost 5 million files: sage:/home/rlmill/tmp# ls -1 a sage:/home/rlmill/tmp# wc -l a 4754843 a (Robert -- Why do you have so many tmp files? Maybe you should be using a database? Filesystems like ext3 aren't good at dealing with 5 million files in a directory...) Anyway, I remounted the filesystem and somehow managed to kill the above job. I then wrote a Python script that is now sitting there deleting those 5 million files one-by-one with a pause between each deletion, so sage.math should feel snappy again: 12062 pts/1S 0:01 python ./del.py -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: file system slowdown on sage.math
William Stein wrote: Hello, On 8/13/07, mabshoff [EMAIL PROTECTED] wrote: I tried rsyncing htdocs to my mirror today and the file system on sage.math is very slow (hours+ to rsync a 120MB file and still waiting on that one). One oddity I came across is this one process: rlmill8598 1.5 0.0 3852 512 pts/16 DN+ 09:53 4:09 rm - rf tmp The DN+ indicates Uninterruptible sleep (usually IO) and low priority. According to top the load on sage.math is around 25, but I don't see any process doing a lot of IO. The number of page faults at the moment is miniscule. The is also one zombie at the moment. Any ideas? Robert Miller was cleaning up his home directories (we ran out of disk space yesterday) and ... 8598 pts/16 DN+7:47 rm -rf tmp The problem is that the directory tmp contains almost 5 million files: lol, you just made my day :) - I have seen much in my 12+ years as sysadmin, but I had never seen 5 Million files in one directory. sage:/home/rlmill/tmp# ls -1 a sage:/home/rlmill/tmp# wc -l a 4754843 a (Robert -- Why do you have so many tmp files? Maybe you should be using a database? Filesystems like ext3 aren't good at dealing with 5 million files in a directory...) Especially since the lookup of directory entries is not hashed. That is coming with ext4. Anyway, I remounted the filesystem and somehow managed to kill the above job. I then wrote a Python script that is now sitting there deleting those 5 million files one-by-one with a pause between each deletion, so sage.math should feel snappy again: 12062 pts/1S 0:01 python ./del.py Mmmmh, so the python script will be done in 5 Million seconds? That will take roughly 2 months time. Oh well, maybe it is time for quoatas ;) -- William Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: quaddouble in sage, and other floating point issues
On 8/13/07, cwitty [EMAIL PROTECTED] wrote: (3a)What I think might be the best idea, at least on Linux, is to change the compilation settings for quad double so that the fpu fix is not needed. There are two ways to do this: If a processor supports sse2, then passing gcc -march=whatever -msse2 -mfpmath=sse (maybe the -march isn't needed) will cause gcc to use sse registers and instructions for doubles, and these have the proper precision. In fact, gcc already does this by default for x86-64 cpus, so the quad double package doesn't even need the fpu fix on those architectures. Also, this has the added benefit of being faster. Yes, this certainly sounds like a good idea. In fact, most of SAGE should be built this way whenever possible. (This might mean having two different binary downloads for x86 Linux, though.) This sounds like the best solution in most cases. Could somebody volunteer to try this, i.e., rebuild the quaddouble package that way, do sage -ba, then run all doctests (make test) and report back with the results? William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: quaddouble in sage, and other floating point issues
On Mon, 2007-08-13 at 10:25 -0700, cwitty wrote: On Aug 11, 6:03 pm, Jonathan Bober [EMAIL PROTECTED] wrote: I have just noticed that using the C type long double from within sage doesn't work the way that I've expected it to. The issue is a little complicated, and other people on this list probably know more about it than I do, but, briefly, the problem stems from the fact that x86 fpu registers support extended precision (64 bit mantissa), while a C double is just double precision (53 bit mantissa). This causes unexpected results sometimes because floating point arithmetic will be done on the processor at extended precision, and then stored in memory at double precision, which means that that value of a double could theoretically change at any time. This is very bad for packages like quaddouble. It is possible to set the fpu control word so that the fpu only uses double precision, which is one way to solve this problem. Apparently, this is done by default on Windows, but not in Linux (and I have no idea about OS X). One problem with this, however, at least on Linux, is that long doubles no longer 64 bits of precision. It seems that, perhaps accidentally, sage is setting the fpu to use double precision. ... There are a few possible ways to fix this, I think. (1)One way is to rewrite the quaddouble wrapper. Then the fpu control word would need to be saved, set, and reset every time arithmetic was done on a quad double (not a good thing, probably). I took a look at the NTL quad float package, and it actually does exactly this. (NTL does this, not the sage wrapper.) (2)Another possibility is to decide that it is a good idea to set the fpu to just use double precision, and to make sure that no sage libraries ever expect extended precision. This might actually be the only really cross platform solution that isn't lots of work -- I'm not sure how long doubles will work on Windows or on OS X. Note that the transcendental functions (trigonometric, etc.) in libm on my Debian Linux box are much more accurate if the fpu is in extended precision mode than if the fpu is in double precision mode. (If you're using RDF floating-point numbers in SAGE, then SAGE will use the gsl_ routines instead of the libm routines. I don't know what the effect of extended precision is on the gsl_ routines. If you're using RealField floating-point numbers, then SAGE uses the mpfr routines, and the fpu is not used at all.) (3a)What I think might be the best idea, at least on Linux, is to change the compilation settings for quad double so that the fpu fix is not needed. There are two ways to do this: If a processor supports sse2, then passing gcc -march=whatever -msse2 -mfpmath=sse (maybe the -march isn't needed) will cause gcc to use sse registers and instructions for doubles, and these have the proper precision. In fact, gcc already does this by default for x86-64 cpus, so the quad double package doesn't even need the fpu fix on those architectures. Also, this has the added benefit of being faster. Yes, this certainly sounds like a good idea. In fact, most of SAGE should be built this way whenever possible. (This might mean having two different binary downloads for x86 Linux, though.) Do people use pre-SSE2 x86 processors to run SAGE? (According to http://en.wikipedia.org/wiki/SSE2, Intel added SSE2 with the Pentium 4 in 2001, and AMD added SSE2 with their 64-bit processors in 2003.) (3b)For processors that don't support sse2, gcc can be passed the -ffloat-store option, which fixes the problem by storing doubles in memory after every operation, ensuring that they are always correctly rounded to double precision. This slows things down a little bit, but would probably be much simpler than option (1). Unfortunately this doesn't work. The float-store option rounds all numbers to double precision, avoiding the problem where a number invisibly changes in the middle of a computation; but it does not correctly round to double precision, so it is not usable for quad double. Are you certain that it is not usable? The NTL quad float package falls back on declaring all doubles volatile when it doesn't know how to change the fpu control word, which should give the same behavior as the -ffloat-store option. From the source comments: The third way to fix the problem is to 'force' all intermediate floating point results into memory. This is not an 'ideal' fix, since it is not fully equivalent to 53-bit precision (because of double rounding), but it works (although to be honest, I've never seen a full proof of correctness in this case). I just tried compiling quad double with the -ffloat-store and with the fpu fix turned off, and it seems to be working. (The tests are still running, but a bunch have passed already.) Personally, I think that I like options 3a and 3b. These would probably require rewriting the
[sage-devel] Re: build dependencies
William Stein wrote: SNIP Hello, I'll wait for the answers to the above questions. I would be fine with including scons in SAGE. I think it's already in one of the optional packages (I can't remember for sure though). It's just a little python program, after all. It would take an absolutely massive amount of convincing to even begin to convince me to include the entire 17MB C++ boost library in SAGE. Well, PolyBori just about destroys any code out there for GBasis-computations over boolean rings including Magma's F4 as well as Faugere's F4 F5. And it isn't only massively faster, but also needs substancially less RAM. Just for the presentation they did in March or so, I am not sure the MEGA paper had any benchmarks in them. Or ask Martin about the CTC examples. It is definitely worth it, espcially if one could cut down the amount of boost code needed to compile. William Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: quaddouble in sage, and other floating point issues
I just tried compiling quad double with the -ffloat-store and with the fpu fix turned off, and it seems to be working. (The tests are still running, but a bunch have passed already.) What I didn't realize when I wrote this email is that the tests should only take a few seconds to run. Turning off the fpu fix and turning on the -ffloat-store option causes one of the tests to run forever, or at least for more than a few minutes (instead of 1 second). So -ffloat-store doesn't work. So on cpus without sse2, the quaddouble wrapper needs to use the fpu fix, but probably should be rewritten so that it doesn't affect other things. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: quaddouble in sage, and other floating point issues
2007/8/11, Jonathan Bober [EMAIL PROTECTED]: cdef class RealQuadDoubleField_class(Field): Real Quad Double Field def __init__(self): fpu_fix_start(self.cwf) def __dealloc__(self): fpu_fix_end(self.cwf) [etc] __dealloc__() is never called until sage exits, however, since a global instance of this class is created at startup. This means that all I didn't realize this, but I don't think RealQuadDoubleField_class needs to set the flags. If one looks at the QuadDoubleElement class, the fpu_fix_*() functions are called every time a quad double number is created and destroyed, which I think is more appropriate. This might be the solution. I haven't actually checked this though (it's late here...). (3a)What I think might be the best idea, at least on Linux, is to change the compilation settings for quad double so that the fpu fix is not needed. There are two ways to do this: If a processor supports sse2, then passing gcc -march=whatever -msse2 -mfpmath=sse (maybe the -march isn't needed) will cause gcc to use sse registers and instructions for doubles, and these have the proper precision. In fact, gcc already does this by default for x86-64 cpus, so the quad double package doesn't even Yes, the fpu_fix_() functions are meant to only work around the weird (depending on your perspective) behavior of x86 cpus. didier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: file system slowdown on sage.math
On Aug 13, 2007, at 18:51 , William Stein wrote: On 8/13/07, mabshoff [EMAIL PROTECTED] dortmund.de wrote: [snip] Robert Miller was cleaning up his home directories (we ran out of disk space yesterday) and ... 8598 pts/16 DN+7:47 rm -rf tmp The problem is that the directory tmp contains almost 5 million files: The file system ain't made that can deal gracefully with that many files in one directory. sage:/home/rlmill/tmp# ls -1 a sage:/home/rlmill/tmp# wc -l a 4754843 a How long did that 'ls' take? 'ls' has to read the whole directory, sort it, and then print it :-}. Next time, use ls -f1, which won't sort the directory; it just takes the entries as they come in the read. (Robert -- Why do you have so many tmp files? Maybe you should be using a database? Filesystems like ext3 aren't good at dealing with 5 million files in a directory...) Inquiring minds want to know... Justin -- Justin C. Walker, Curmudgeon-at-Large () The ASCII Ribbon Campaign /\ Help Cure HTML Email --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
