[sage-devel] Re: AbelianGroup's subgroups
On Oct 4, 4:54 am, William Stein wst...@gmail.com wrote: On Sat, Oct 3, 2009 at 8:07 PM, Rob Beezer goo...@beezer.cotse.net wrote: On Oct 3, 6:05 pm, William Stein wst...@gmail.com wrote: And this has already been almost completed by David Loeffler based on work by me. http://trac.sagemath.org/sage_trac/ticket/6449 The work at #6449 creates additive abelian groups by extending the class for finitely-generated modules over ZZ. Assuming that approach, is there a natural way to get all the subgroups? I don't think so. I have a hazy recollection that maybe a book by Henri Cohen on explicit class field theory has such an algorithm nicely described... If so, I'm not seeing it. Or would David Loeffler's routine for all subgroups of a multiplicative abelian group need to be translated to the additive version? Probably the latter. David Loeffler might want to comment, since I cc'd him. Rob -- William Stein Associate Professor of Mathematics University of Washingtonhttp://wstein.org I wrote both the subgroups method of the old ab groups class and the draft replacement class. The old subgroups method is essentially secretly using the new approach under the hood -- it relies on the Smith form routines for integer matrices -- so it would not be difficult to translate the old code into the new framework. But it has not been done so far. The status of abelian groups in Sage at the moment is as follows. At SD16 a project to revise abelian groups was announced; a number of people voluteered to take part; a design discussion took place, and I volunteered to write the first draft code; a few days later I had some code working and I demoed this back to the group, feeling that I had done my job and it was time for one of the five or six others who had declared an interest in the project to take over; and since then the code has sat there bitrotting on trac, and nothing has happened except people sending me nagging emails attempting to persuade me to do yet more work on it solo. David --~--~-~--~~~---~--~~ 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: AbelianGroup's subgroups
Sorry, I've just seen William's earlier post in this thread, and I see that there was no need for my rather combative previous post -- I apologise for any offence I may have caused. David On Oct 4, 2:05 am, William Stein wst...@gmail.com wrote: On Sat, Oct 3, 2009 at 1:30 PM, David Joyner wdjoy...@gmail.com wrote: The abelian group class needs to be rewritten. The basic idea was to try to use GAP as much as possible and use Python/Sage to parse input and output. For various technical reasons, that did not work as nicely as hoped. The correct solution, may be to rewrite it from scratch completely separate from GAP. And this has already been almost completed by David Loeffler based on work by me. http://trac.sagemath.org/sage_trac/ticket/6449 David is done working on that so somebody else has a chance to be a hero and step up and finish it. Go somebody! Whoever you are, if you finish this, you'll be the first to successfully rewrite abelian groups, after about 7 people have tried and failed. Time to clime Everest. -- William This doesn't answer your question, but I hope gives you confidence that if you think that something is odd about the implementation and you want to change it, then you are probably correct. On Sat, Oct 3, 2009 at 3:43 PM, Rob Beezer goo...@beezer.cotse.net wrote: The AbelianGroup class has an extremely welcome method that manufactures all subgroups of a finite abelian group. These groups are a big part of an introductory group theory course, so to be able to list and inspect all subgroups is a really great feature that I wish was more widespread. However, I've stumbled across the following behavior (demonstrated here in Z/2Z x Z/4Z), which I think will be very confusing to students, since it gave me pause: sage: G=AbelianGroup([2,4]) sage: K=G.subgroups()[1] sage: K Multiplicative Abelian Group isomorphic to C2 x C2, which is the subgroup of Multiplicative Abelian Group isomorphic to C2 x C4 generated by [f1^2, f0] sage: K.gens() [f1^2, f0] sage: K.list() [1, f1, f0, f0*f1] At first glance it looks like the generator f1^2 is not an element of the subgroup! The explanation is that the generators are reported in terms of the two generators of the full Z/2Z x Z/4Z group G (f0, f1), while the elements of the subgroup K are reported using conceptually new names for its two generators. In effect there are assignments f1 = f1^2, f0 = f0 in moving to the elements of the subgroup. Other examples with smaller subgroups of larger groups can get more complicated, where the indexing also seems to shift downward for the subgroup. So subgroups are being reported as isomorphic copies rather than as subsets of the group, while retaining enough information to reconstruct them as subsets. This certainly makes great sense for a compact manageable internal representation, but does it make sense to report elements of the subgroup relative to the isomorphic representation or in terms of the full (ambient) group? Seemingly related to this, subgroups are implemented with their own class, which does not seem to permit always obtaining subgroups of subgroups - there appears to be something like a check that the set of names used are equal, which raises an error since they can be more mismatched than in the above example. In the definition of K above, switch the index to 5 and ask for K's subgroups to see this error behavior. At a minimum this would seem to be a bug, because this action seems to work correctly for the original K. I'm building a class for the group of units mod n, mostly on top of this AbelianGroup implementation. So far, I just represent subgroups with the same class that I use for the full group. Would this be a bad idea for the AbelianGroup class (or is it a bad idea for the class I'm building)? Or would there be a way to (optionally) have a subgroup report its elements in terms of the full group? I don't see a command to realize a subgroup as a subset of the original group, but maybe the reverse would make sense: you get a subgroup that is a subset, unless you ask explicitly for an isomorphic version? Is the current, or the suggested, behavior totally inconsistent with what is done elsewhere in Sage? Clarifications, unexplored commands, workarounds, policies, suggestions, opinions, sympathy all welcome. Thanks. Rob -- William Stein Associate Professor of Mathematics University of Washingtonhttp://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] Re: Sage 4.1.2.rc0 released
Building on 64-bit SuSE with SAGE_CHECK=yes failed at libgcrypt, with a bunch of errors in the gcrypt test script: make[4]: Entering directory `/home/david/sage-4.1.2.rc0/spkg/build/ libgcrypt-1.4.3.p2/src/tests' version:1.4.0: ciphers:arcfour:blowfish:cast5:des:aes:twofish:serpent:rfc2268:seed:camellia: pubkeys:dsa:elgamal:rsa:ecc: digests:crc:md4:md5:rmd160:sha1:sha256:sha512:tiger:whirlpool: rnd-mod:linux: mpi-asm:amd64/mpih-add1.S:amd64/mpih-sub1.S:amd64/mpih-mul1.S:amd64/ mpih-mul2.S:amd64/mpih-mul3.S:amd64/mpih-lshift.S:amd64/mpih-rshift.S: hwflist: PASS: version PASS: t-mpi-bit PASS: prime PASS: register PASS: ac PASS: ac-schemes PASS: ac-data Rijndael-128 test encryption failed. algo 7, mode 1, gcry_cipher_setkey failed: Selftest failed algo 7, mode 2, gcry_cipher_setkey failed: Selftest failed algo 7, mode 5, gcry_cipher_setkey failed: Selftest failed algo 7, mode 3, gcry_cipher_setkey failed: Selftest failed algo 7, mode 3, gcry_cipher_setkey failed: Selftest failed algo 7, mode 6, gcry_cipher_setkey failed: Selftest failed algo 8, mode 1, gcry_cipher_setkey failed: Selftest failed algo 8, mode 2, gcry_cipher_setkey failed: Selftest failed algo 8, mode 5, gcry_cipher_setkey failed: Selftest failed algo 8, mode 3, gcry_cipher_setkey failed: Selftest failed algo 8, mode 3, gcry_cipher_setkey failed: Selftest failed algo 8, mode 6, gcry_cipher_setkey failed: Selftest failed algo 9, mode 1, gcry_cipher_setkey failed: Selftest failed algo 9, mode 2, gcry_cipher_setkey failed: Selftest failed algo 9, mode 5, gcry_cipher_setkey failed: Selftest failed algo 9, mode 3, gcry_cipher_setkey failed: Selftest failed algo 9, mode 3, gcry_cipher_setkey failed: Selftest failed algo 9, mode 6, gcry_cipher_setkey failed: Selftest failed aes-cbc-cts, gcry_cipher_setkey failed: Selftest failed cbc-mac algo 7, gcry_cipher_setkey failed: Selftest failed aes-ctr, gcry_cipher_setkey failed: Selftest failed aes-cfb, gcry_cipher_setkey failed: Selftest failed aes-ofb, gcry_cipher_setkey failed: Selftest failed FAIL: basic PASS: mpitests PASS: tsexp PASS: keygen PASS: pubkey PASS: hmac PASS: keygrip PASS: random MD5 0ms10ms30ms SHA1 0ms10ms70ms RIPEMD160 10ms10ms40ms TIGER192 0ms20ms30ms SHA256 10ms20ms40ms SHA384 10ms20ms40ms SHA512 10ms20ms50ms SHA224 10ms20ms40ms MD4 0ms10ms30ms CRC32 10ms 0ms20ms CRC32RFC1510 0ms10ms10ms CRC24RFC244030ms20ms40ms WHIRLPOOL 20ms20ms40ms ECB CBC CFB OFB CTR STREAM --- --- --- --- --- --- 3DES70ms70ms80ms70ms70ms70ms 70ms80ms80ms80ms CAST5 20ms20ms30ms20ms30ms20ms 20ms30ms30ms30ms BLOWFISH20ms20ms20ms20ms30ms20ms 30ms20ms40ms30ms AES Rijndael-128 test encryption failed. gcry_cipher_setkey failed: Selftest failed FAIL: benchmark 2 of 16 tests failed Please report to bug-libgcr...@gnupg.org make[4]: *** [check-TESTS] Error 1 make[4]: Leaving directory `/home/david/sage-4.1.2.rc0/spkg/build/ libgcrypt-1.4.3.p2/src/tests' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/home/david/sage-4.1.2.rc0/spkg/build/ libgcrypt-1.4.3.p2/src/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/home/david/sage-4.1.2.rc0/spkg/build/ libgcrypt-1.4.3.p2/src' make check failed for libgcrypt * Error testing package ** libgcrypt-1.4.3.p2 ** * --~--~-~--~~~---~--~~ 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: Sage 4.1.2.rc0 released
I will give it a try once the current build has finished. David On Oct 1, 12:39 pm, Minh Nguyen nguyenmi...@gmail.com wrote: Hi David, On Thu, Oct 1, 2009 at 9:36 PM, davidloeffler dave.loeff...@gmail.com wrote: Building on 64-bit SuSE with SAGE_CHECK=yes failed at libgcrypt, with a bunch of errors in the gcrypt test script: Can you try using the updated libgcrypt spkg at ticket #7045 [1]? [1]http://trac.sagemath.org/sage_trac/ticket/7045 -- Regards Minh Van Nguyen --~--~-~--~~~---~--~~ 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: Sage 4.1.2.rc0 released
I've come up with another error. This is the first time I've built with SAGE_CHECK set, so it's running all the test suites in all the packages, and quaddouble fails: Successfully installed quaddouble-2.2.p9 Running the test suite. make[2]: Entering directory `/home/david/sage-4.1.2.rc0/spkg/build/ quaddouble-2.2.p9/src' Making check in config make[3]: Entering directory `/home/david/sage-4.1.2.rc0/spkg/build/ quaddouble-2.2.p9/src/config' make[3]: Nothing to be done for `check'. make[3]: Leaving directory `/home/david/sage-4.1.2.rc0/spkg/build/ quaddouble-2.2.p9/src/config' Making check in src make[3]: Entering directory `/home/david/sage-4.1.2.rc0/spkg/build/ quaddouble-2.2.p9/src/src' make[3]: Nothing to be done for `check'. make[3]: Leaving directory `/home/david/sage-4.1.2.rc0/spkg/build/ quaddouble-2.2.p9/src/src' Making check in include make[3]: Entering directory `/home/david/sage-4.1.2.rc0/spkg/build/ quaddouble-2.2.p9/src/include' make[3]: Nothing to be done for `check'. make[3]: Leaving directory `/home/david/sage-4.1.2.rc0/spkg/build/ quaddouble-2.2.p9/src/include' Making check in tests make[3]: Entering directory `/home/david/sage-4.1.2.rc0/spkg/build/ quaddouble-2.2.p9/src/tests' make qd_test pslq_test make[4]: Entering directory `/home/david/sage-4.1.2.rc0/spkg/build/ quaddouble-2.2.p9/src/tests' g++ -DHAVE_CONFIG_H -I.. -I../include -I../include -fPIC -O3 - Dx86 -MT qd_test.o -MD -MP -MF .deps/qd_test.Tpo -c -o qd_test.o qd_test.cpp qd_test.cpp:25: error: ‘std::strcmp’ has not been declared qd_test.cpp:26: error: ‘std::exit’ has not been declared qd_test.cpp: In function ‘int main(int, char**)’: qd_test.cpp:374: error: ‘strcmp’ was not declared in this scope qd_test.cpp:376: error: ‘exit’ was not declared in this scope make[4]: *** [qd_test.o] Error 1 make[4]: Leaving directory `/home/david/sage-4.1.2.rc0/spkg/build/ quaddouble-2.2.p9/src/tests' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/home/david/sage-4.1.2.rc0/spkg/build/ quaddouble-2.2.p9/src/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/home/david/sage-4.1.2.rc0/spkg/build/ quaddouble-2.2.p9/src' * Error testing package ** quaddouble-2.2.p9 ** * This looks like a bug in the quaddouble test script, rather than in quaddouble itself. --~--~-~--~~~---~--~~ 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: Sage 4.1.2.rc0 released
On Oct 1, 4:15 pm, William Stein wst...@gmail.com wrote: On Thu, Oct 1, 2009 at 6:47 AM, davidloeffler dave.loeff...@gmail.com wrote: I've come up with another error. This is the first time I've built with SAGE_CHECK set, so it's running all the test suites in all the packages, and quaddouble fails: The list of standard Sage packages that fail their own test suites is getting worryingly long -- as well as quaddouble and libgcrypt, I'm getting failures from R, pyprocessing, and sqlalchemy. --~--~-~--~~~---~--~~ 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: Sage 4.1.2.rc0 released
On Oct 1, 12:39 pm, Minh Nguyen nguyenmi...@gmail.com wrote: Hi David, On Thu, Oct 1, 2009 at 9:36 PM, davidloeffler dave.loeff...@gmail.com wrote: Building on 64-bit SuSE with SAGE_CHECK=yes failed at libgcrypt, with a bunch of errors in the gcrypt test script: Can you try using the updated libgcrypt spkg at ticket #7045 [1]? [1]http://trac.sagemath.org/sage_trac/ticket/7045 -- Regards Minh Van Nguyen The new spkg 1.4.4.p0 seems to fix the problem. David --~--~-~--~~~---~--~~ 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: Sage 4.1.2.rc0 released
On Oct 1, 4:28 pm, William Stein wst...@gmail.com wrote: On Thu, Oct 1, 2009 at 8:23 AM, davidloeffler dave.loeff...@gmail.com wrote: On Oct 1, 4:15 pm, William Stein wst...@gmail.com wrote: On Thu, Oct 1, 2009 at 6:47 AM, davidloeffler dave.loeff...@gmail.com wrote: I've come up with another error. This is the first time I've built with SAGE_CHECK set, so it's running all the test suites in all the packages, and quaddouble fails: The list of standard Sage packages that fail their own test suites is getting worryingly long -- as well as quaddouble and libgcrypt, I'm getting failures from R, pyprocessing, and sqlalchemy. Pyprocessing is a standard part of Python 2.6, so I have no idea why it's included in Sage as a separate package. Removing it is trac 6503: http://trac.sagemath.org/sage_trac/ticket/6503 Unfortunately, I can't think of an argument to remove R or sqlalchemy! :-) Open tickets for the check failures of those. William -- William Stein Associate Professor of Mathematics University of Washingtonhttp://wstein.org These are now #7090 and #7091. --~--~-~--~~~---~--~~ 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: Sage 4.1.1.alpha0 released
I'm seeing some errors building the reference manual, from sage/ schemes/elliptic_curves/ell_rational_field.py and sage/databases/ jones.py. Presumably these are coming from the tickets #6045: Robert Bradshaw: Computation of Heegner points [Reviewed by John Cremona, Minh Van Nguyen] #6332: Francis Clarke: optional doctest failure -- jones number field database tests fail [Reviewed by Alex Ghitza] This is now #6577. David On Jul 21, 9:28 am, Alex Ghitza aghi...@gmail.com wrote: On Tue, Jul 21, 2009 at 5:55 PM, Minh Nguyennguyenmi...@gmail.com wrote: On Tue, Jul 21, 2009 at 1:04 PM, Minh Nguyennguyenmi...@gmail.com wrote: Hi folks, This is the first release of the Sage 4.1.1 release cycle. William and I are co-chairing this release cycle. The source tarball and the sage.math only binary are available at http://sage.math.washington.edu/home/mvngu/release/sage-4.1.1.alpha0.tar http://sage.math.washington.edu/home/mvngu/release/sage-4.1.1.alpha0-... You can also upgrade using this path: http://sage.math.washington.edu/home/mvngu/release/sage-4.1.1.alpha0/ Upgraded from 4.1 and passed make ptestlong on a 32-bit archlinux machine. -- Alex Ghitza -- Lecturer in Mathematics -- The University of Melbourne -- Australia --http://www.ms.unimelb.edu.au/~aghitza/ --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.1.1.alpha0 released
On Jul 21, 10:56 am, davidloeffler dave.loeff...@gmail.com wrote: I'm seeing some errors building the reference manual, from sage/ schemes/elliptic_curves/ell_rational_field.py and sage/databases/ jones.py. Presumably these are coming from the tickets #6045: Robert Bradshaw: Computation of Heegner points [Reviewed by John Cremona, Minh Van Nguyen] #6332: Francis Clarke: optional doctest failure -- jones number field database tests fail [Reviewed by Alex Ghitza] This is now #6577. Patch up at http://trac.sagemath.org/sage_trac/ticket/6577; this is an easy one for someone to review. David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: printing and latex representation of multivariate polynomials
Could someone point me to a reason why anything should be printed as 1.*var? To remind you that the computation you're doing is only correct to 8 decimal places? If you want exact computations you shouldn't be using the real field as base. David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage -upgrade 4.0 to 4.1
On Jul 13, 10:59 pm, Jaap Spies j.sp...@hccnet.nl wrote: I think the documentation build system needs some polishing. It's not really the fault of the documentation build system; it's the upgrade and clone scripts that are at fault. In particular, the decision to use hard links for the documentation build system when cloning -- a new feature introduced by #5350 -- was a spectacularly terrible idea. The cloning issue is being tracked at #6187; I'm not sure if there's a ticket open for the upgrade behaviour. David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage-4.1
On Jul 13, 8:24 am, Minh Nguyen nguyenmi...@gmail.com wrote: As it now stands, the HTML version of the reference manual of Sage 4.1.1 is bit broken. You can build the HTML version. However, if the docstring for a function or class uses the .. MATH:: tag, then it won't render in the generated HTML version. This issue was reported in the sage-devel thread http://groups.google.com/group/sage-devel/browse_thread/thread/cb1687... and the corresponding ticket is #6512. FWIW: I tried to get around this by using sage -docbuild --jsmath reference html. This led to a new problem, which this snippet from sage/rings/polynomial/toy_d_basis shows: We first form a certain ideal I in [Unknown control sequence '\ZZ'], and note that the Groebner basis of I over [Unknown control sequence '\QQ'] contains 1, so there are no solutions over [Unknown control sequence '\QQ'] or an algebraic closure of it... It looks like jsmath doesn't know about the Sage's set of TeX macros \ZZ, \QQ, \GF, etc. Is this a known issue, or should I open a new ticket? David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage-4.1.rc1
On Jul 9, 9:02 am, Pat LeSmithe qed...@gmail.com wrote: Minh Nguyen wrote: Note that I have already deleted the experimental repository sage-exp, but the documentation build script (I think) still links to or uses that deleted repository. This might be due to ticket #5350 http://trac.sagemath.org/sage_trac/ticket/5350 but I may be wrong here. I don't get the above problem if I make clones of the main repository and don't delete them. But that eats up a lot of disk space, even though /scratch on sage.math is pretty large in terms of storage. And sometimes I remove repositories because I don't need them any more. Thanks for noting this. This is one of the problems we're trying to eliminate at http://trac.sagemath.org/sage_trac/ticket/6187 I will try to update the current patches so that the builder does not throw an error, if an auto-generated .rst file is missing. I'm seeing a possibly related problem. I have a branch X, in which I have done a patch that adds lots of files to the reference manual. If I build docs in branch X, then switch to a different branch Y and try and build docs there, I get loads of warnings about bad formatting in the relevant files, since somehow the ReST parser can still see them, and sees the un-edited versions with non-ReSTified docstrings -- even though they're not linked into the reference manual in branch Y! How on earth can this happen? (In fact the problem is even more severe than that: I can't now build docs in any other branch except X, because in branch X I added sage/ structure/category_object.pyx to the manual; and without some (minor) editing that file crashes the documentation builder, due to a slightly bizarre Cython class that overrides the __doc__ attribute.) David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Unpickling problem
This is now #6462. (I have played with it a bit myself, and I can get pickling and unpickling to work, by defining a __reduce__ function for orders, and adjusting the __reduce__ function for number field elements; but now the standard x == loads(dumps(x)) test doesn't seem to work.) David On Jul 3, 6:13 pm, daveloeffler dave.loeff...@gmail.com wrote: I'm having trouble with unpickling some elements of an order in a quadratic number field. If I do sage: L = QuadraticField(-11,'a'); OL = L.maximal_order(); w = OL.0 sage: loads(dumps(w)) then I get a traceback ending with AttributeError: 'AbsoluteOrder' object has no attribute '_is_maximal' With orders in higher-degree fields, I get a different error message: sage: L = NumberField(x^3 - x - 1,'a'); OL = L.maximal_order(); w = OL. 0 sage: loads(dumps(w)) ... AttributeError: 'NumberField_absolute' object has no attribute 'number_field' (and the analogous thing for relative fields as well.) Any suggestions? This is a real problem because I am working on a computation where I need to be able to save results to disc, and this result is preventing me from loading what I've saved. (Elements of the fields rather than the orders unpickle OK, but it's next to impossible to prevent elements of the orders creeping in somehow when I pickle stuff.) David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Unpickling problem
It is indeed a bit strange that OrderElement derives from FieldElement. But my diagnosis was different: Parent classes that have attributes which are Elements cause problems for the default Python unpickler. For instance, if X is an AbsoluteOrder, then loads(dumps(X)) works and equals X, *as long as you don't do anything with X first*. If you do anything with X, then X._AbsoluteOrder__basis will be set to a list of elements of X; and then X becomes unpickleable. The reason I had trouble getting to the bottom of it at first was that the tracebacks were all mangled. The reason for this is subtle: some of the error reporting code was trying to call _repr_ on an AbsoluteOrder object that was only half-unpickled and hence missing some attributes, which meant that _repr_ was itself raising an exception. Hence the error was reported with the error message for the second exception, but with the line numbers for the first! David On Jul 4, 12:46 pm, William Stein wst...@gmail.com wrote: On Sat, Jul 4, 2009 at 1:25 PM, davidloefflerdave.loeff...@gmail.com wrote: This is now #6462. (I have played with it a bit myself, and I can get pickling and unpickling to work, by defining a __reduce__ function for orders, and adjusting the __reduce__ function for number field elements; but now the standard x == loads(dumps(x)) test doesn't seem to work.) I think the problem stems from the weird design of order elements. They are really quadratic number field elements, but they have their parents brutally changed to be an order instead. Since this design was Robert Bradshaw's clever idea, if he has time, perhaps he will be able to make a comment. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Unpickling problem
Patch is now up at: http://trac.sagemath.org/sage_trac/ticket/6462 David On Jul 4, 2:14 pm, davidloeffler dave.loeff...@gmail.com wrote: It is indeed a bit strange that OrderElement derives from FieldElement. But my diagnosis was different: Parent classes that have attributes which are Elements cause problems for the default Python unpickler. For instance, if X is an AbsoluteOrder, then loads(dumps(X)) works and equals X, *as long as you don't do anything with X first*. If you do anything with X, then X._AbsoluteOrder__basis will be set to a list of elements of X; and then X becomes unpickleable. The reason I had trouble getting to the bottom of it at first was that the tracebacks were all mangled. The reason for this is subtle: some of the error reporting code was trying to call _repr_ on an AbsoluteOrder object that was only half-unpickled and hence missing some attributes, which meant that _repr_ was itself raising an exception. Hence the error was reported with the error message for the second exception, but with the line numbers for the first! David On Jul 4, 12:46 pm, William Stein wst...@gmail.com wrote: On Sat, Jul 4, 2009 at 1:25 PM, davidloefflerdave.loeff...@gmail.com wrote: This is now #6462. (I have played with it a bit myself, and I can get pickling and unpickling to work, by defining a __reduce__ function for orders, and adjusting the __reduce__ function for number field elements; but now the standard x == loads(dumps(x)) test doesn't seem to work.) I think the problem stems from the weird design of order elements. They are really quadratic number field elements, but they have their parents brutally changed to be an order instead. Since this design was Robert Bradshaw's clever idea, if he has time, perhaps he will be able to make a comment. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage -merge problem
I got the same thing; and when I added a single quote in the obvious place, I got a new error: Traceback (most recent call last): File /home/david/sage-4.1/local/bin/sage-apply-ticket, line 20, in module import sage.misc.hg as hg File /home/david/sage-4.1/devel/sage-unflaking/sage/misc/hg.py, line 43, in module from misc import tmp_filename, branch_current_hg, embedded File /home/david/sage-4.1/devel/sage-unflaking/sage/misc/misc.py, line 28, in module import sage.misc.prandom as random File /home/david/sage-4.1/devel/sage-unflaking/sage/misc/ prandom.py, line 56, in module from sage.misc.randstate import current_randstate ImportError: No module named randstate On Jul 3, 9:52 am, John Cremona john.crem...@gmail.com wrote: On a fresh clone of a freshly-built 4.1.alpha3: j...@host-57-44%sage -merge File /home/jec/sage-4.1.alpha3/local/bin/sage-apply-ticket, line 464 os.chdir(SAGE_ROOT+'/tmp) ^ SyntaxError: EOL while scanning string literal Should there be a second quote before the ) ? John --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: 4.1.alpha2 released
On Jun 27, 11:54 pm, davidloeffler dave.loeff...@gmail.com wrote: On SuSE, 32-bit, sage -testall -long passes except for errors in the same three files Jaap reported above (and a harmless timeout in elliptic curves). I spoke too soon. Something rather harmful has in fact happened: the wrong patches have been merged for track #5080. My first attempt at fixing this problem caused a catastrophic slowdown in elliptic curve Sha routines, so I started again from scratch and did a new patch that worked differently. It seems that the old patch has been merged, with the result that sage: EllipticCurve(858k1).sha().an_padic(7) has been slowed down by *several orders of magnitude*. That was why I was seeing timeouts in that file. To reiterate: the patch trac_5080.patch on that ticket is evil, bad and wrong, should not have been merged, and must be removed from Sage ASAP. David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: 4.1.alpha2 released
I've got a build running on my laptop at the moment, and I was wondering: why does the install script not run the Flint test suite? I'm puzzled by this since it did run Flint tests when I installed 4.0.2, which was actually the same Flint spkg version (flint-1.3.0.p1.spkg) David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: 4.1.alpha2 released
On SuSE, 32-bit, sage -testall -long passes except for errors in the same three files Jaap reported above (and a harmless timeout in elliptic curves). Craig: thanks for pointing out SAGE_CHECK. But it strikes me that there is no way I can run those tests now, without recompiling the corresponding spkgs from scratch. Is there any way one can get spkgs to provide a test script, separate from the installation procedure, so something like sage -tspkg flint-xxx.spkg would run the tests for Flint? David On Jun 27, 9:08 pm, Jaap Spies j.sp...@hccnet.nl wrote: Tom Boothby wrote: Sage 4.1.alpha2 has been released, find it at http://sage.math.washington.edu/home/boothby/releases As with 4.1.alpha1, there are two known doctest failures. One is very simple to fix, and the other might be tricky. I made an attempt at solving them, but William claims that my fix will break osx10.4. I'd appreciate it if somebody could take a look at this. On Fedora 9, 32 bit: -- The following tests failed: sage -t devel/sage/doc/fr/tutorial/programming.rst sage -t devel/sage/sage/graphs/graph.py sage -t devel/sage/sage/misc/darwin_utilities.pyx Jaap --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0.2.rc0 released
On Jun 16, 2:15 am, Nick Alexander ncalexan...@gmail.com wrote: On 15-Jun-09, at 4:22 PM, John H Palmieri wrote: Someone didn't format their reST correctly, so building the reference manual now produces warnings/errors. Has the reference manual ever built correctly? (I always get tons of noise and tons of warnings.) I didn't enforce a clean manual when I was release manager because we didn't appear to start with a clean manual. I worked pretty hard to get it to build cleanly in 4.0, see patch 6149, and I think the final 4.0 release has a 100% clean reference manual. As soon as we got to 4.0.1.alpha0 it was broken again. But then, one of the patches that is generating an error above was reviewed by me, so I am as much at fault as anybody. I actually got an error (rather than a warning) from the docstring for elliptic curve period lattices -- a typo, \signa, had confused LaTeX. David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage-4.0.2.rc1
I notice that you still have libm4ri-20090512.spkg in this version, rather than malb's updated libm4ri-20090615.spkg. Is this deliberate? The former failed to build for lots of people (including me). David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage-4.0.2.rc1
Wow, that's a fast release cycle :-) On Jun 16, 12:34 pm, William Stein wst...@gmail.com wrote: On Tue, Jun 16, 2009 at 12:28 PM, davidloefflerdave.loeff...@gmail.com wrote: I notice that you still have libm4ri-20090512.spkg in this version, rather than malb's updated libm4ri-20090615.spkg. Is this deliberate? No, it is not deliberate. There is now an rc2 with this fixed an some other things fixed: http://sage.math.washington.edu/home/wstein/farm/src/sage-4.0.2.rc2.tar Craig just made the above, by the way. William The former failed to build for lots of people (including me). David -- William Stein Associate Professor of Mathematics University of Washingtonhttp://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0.2.rc0 released
Is there a copy anywhere we can use with sage -upgrade? David On Jun 15, 9:13 am, Nick Alexander ncalexan...@gmail.com wrote: Hi all, Here's Sage 4.0.2.rc0. Come and get it while it's hot: http://sage.math.washington.edu/home/ncalexan/releases We merged all of the tickets with positive review on trac (save one that depended on a still-unreviewed ticket), and updated to the current upstream for seven spkgs. You're probably wondering why this is rc0 instead of alpha0 -- we'd like to get 4.0.2 pushed out the door pretty soon, and we've already merged all the code we could from trac, so we're cutting it off here. In addition, William is giving a talk at MEGA on Thursday, and it would be nice to have a fresh new release for that. So please build and test soon, and we'll get this tested and released. == Notable new features == * Updated to current upstream of Singular, MPIR, FLINT, numpy, scipy, m4ri, and pynac * sage -br calls gcc in parallel when MAKE is set * New script for automatically downloading and testing patches from a trac ticket -- this was used to create this release, but will be packaged with rc1 == Known issues == * There's a doctest failure with Singular on 32-bit machines, where Singular seems to be choosing different representatives for the integers mod 2^32 on 32 and 64 bit architectures. Martin Albrecht will hopefully chime in on the right fix for this. * The new scipy will have doctest failures with gfortran, but works fine with g95. In particular, we patch scipy.optimize.optimize for g95, but not gfortran -- and the unpatched version has unusual behavior for find_maximum_on_interval (which calls scipy.optimize.optimize.fminbound). == List of closed tickets == This will come with the release email for the next rc; if you want to see it right away, it's here: http://trac.sagemath.org/sage_trac/query?status=closedgroup=resoluti... Thanks, -Craig and Nick --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage-4.0.2 release timeline
Can I make a special request for this release? It would be really nice if we could get rid of the insufferable WARNING: html_favicon is not an .ico file on building the documentation. Inspection reveals that the favicon is set to output/html/en/blah/_static/sageicon.png, which is not an .ico file nor any other kind of file for that matter -- the file does not exist. We can't do this through trac patches, as it needs a binary file to be added -- Nick or Craig, can you sort this one out? David On Jun 8, 6:22 am, Nick Alexander ncalexan...@gmail.com wrote: Hi everyone, Craig Citro and I (Nick Alexander) are your humble release managers for this iteration, sage-4.0.2. The plan is to cut a release candidate Friday, June 12, probably evening PST. The release itself will be Saturday, June 13. Hopefully Minh will update the release notes and Harald the website shortly afterward. We are going to try to merge all the code on trac that currently has a positive review. However, there are a significant number of patches needing review; now is the time to campaign for reviews. Please email reviewers ASAP! You can also add them to the cc field on trac, possibly using the list on the front page of trac (http://trac.sagemath.org/sage_trac/ ) to help map names to trac usernames. If you can't think of a suitable reviewer for one of your patches, Craig and I will try to assist. We intend to upgrade the following software: * Singular * Scipy * Numpy * mpir There was some talk about merging the categories code of the sage- combinat group. Since much of this code is still under review, that won't happen this iteration. Sorry! Hopefully a push can be made to get this in for sage-4.1. Nick (for Craig) --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: annoying upgrade thing
On Jun 8, 1:05 pm, William Stein wst...@gmail.com wrote: Just out of curiosity, if you do sage -upgrade again, does it build the documentation yet again? William Yes, it does. David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: What can Magma do that Sage can't do?
On Jun 6, 3:47 am, William Stein wst...@gmail.com wrote: * Galois theory and ramification groups for p-adic extensions (needs the previous features) I wrote a (very simplistic) implementation of Artin symbols and decomposition and ramification groups a few months back for extensions of *number fields*, so we have this via the canonical dumb algorithm: find an extension of number fields whose local extension at some prime is the p-adic extension you want. VII. Modules * Sage has nothing for modules over Dedekind domains (except over ZZ): this is an extremely important building block for certain algorithms (e.g., arithmetic in quaternion algebras over number fields), so needs to get implemented. I recently wrote code for general modules over ZZ, but it isn't in Sage yet. PROJECT: Finish modules over ZZ, optimize PROJECT: Extend modules over ZZ to modules over a PID Last week I wrote some code for Hermite form, which is the key linear- algebra step for this; see trac #6178. So we have free modules over an arbitrary PID (me) and arbitrary fg modules over ZZ (you), and combining these probably won't be very hard. David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0.1.alpha0 released!
\begin{grumble}
For me, 4.0.1.alpha0 builds successfully on 32-bit Linux (upgrading
from 4.0). But there are a bunch of errors building the reference
manual, coming from sage.combinat.backtrack.SearchForest. This is
rather frustrating given the hours of work I put in to making sure the
4.0 docs build cleanly.
Come on, guys; is it really so hard to run sage -docbuild reference
html and check the output before you submit (or give a positive
review to) a patch?
\end{grumble}
David
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0.1.alpha0 released!
On Jun 2, 4:35 pm, kcrisman kcris...@gmail.com wrote: Though I'll point out, for the sake of argument, that some of us have such underpowered computers that even running full doctests is not practical (i.e. everything times out), and given how long it takes to build the documentation whenever I even upgrade, there could be circumstances where this is also less practical. Is there a way to run the docbuild just on one file/one set of files? Upgrading forces a full rebuild of the documentation, but importing a new patch and rebuilding the documentation shouldn't - it should only build the files that have changed. What does force a complete rebuild is making a new branch with sage - clone. This is annoying; I don't know enough about the build machinery to know if this can be changed. David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0.rc1 released!
At the end of the compilation, when it generates the reference manual,
I'm getting a huge bunch of warning messages from the Sphinx parser.
These are due to badly formatted ReST docstrings. I've opened a ticket
(#6149) and uploaded a patch -- any volunteers to review this? It
would look a bit unprofessional to have all these errors in the final
4.0 release.
David
On May 28, 1:04 pm, Jaap Spies j.sp...@hccnet.nl wrote:
Mike Hansen wrote:
Hello,
Sage 4.0.rc1 has been released. This should hopefully take care of
the rest of the fallout from the switch to Pynac. The tarball can be
found at
http://sage.math.washington.edu/home/mhansen/sage-4.0.rc1.tar
and a copy of it to be used for upgrading can be found at
http://sage.math.washington.edu/home/mhansen/release/4.0/rc1/sage-4.0...
On Fedora 10, 32 bit, upgraded from rc0:
--
The following tests failed:
sage -t devel/sage/sage/matrix/matrix2.pyx
sage -t devel/sage/sage/symbolic/expression.pyx
sage -t devel/sage/sage/matrix/matrix2.pyx
**
File
/home/jaap/Download/sage-4.0.alpha0/devel/sage/sage/matrix/matrix2.pyx,
line 4964:
sage: m.change_ring(CDF).eigenvalues() # again for display purposes
Expected:
[10.463115298 - 4.98835989975e-16*I, 7.42365754809 -
5.05298436852e-16*I, 3.36964641458 + 5.59670199836e-17*I, 1.25904669699 +
4.34508443713e-17*I,
0.00689184179485 - 5.75358699674e-17*I, 0.330700789655 + 5.1816322259e-16*I]
Got:
[10.463115298 - 4.46500755169e-16*I, 7.42365754809 +
1.02246204259e-16*I, 3.36964641458 - 2.25910315504e-16*I, 1.25904669699 +
7.13217318887e-17*I,
0.00689184179485 - 3.00110164897e-16*I, 0.330700789655 + 1.23712186398e-16*I]
**
1 items had failures:
1 of 36 in __main__.example_81
sage -t devel/sage/sage/symbolic/expression.pyx
**
File
/home/jaap/Download/sage-4.0.alpha0/devel/sage/sage/symbolic/expression.pyx,
line 4395:
sage: maxima('atanh(0.5)')
Expected:
.5493061443340548
Got:
.5493061443340549
**
File
/home/jaap/Download/sage-4.0.alpha0/devel/sage/sage/symbolic/expression.pyx,
line 946:
sage: hash(x^y)
Expected:
4043309056
Got:
-251658240
**
2 items had failures:
1 of 9 in __main__.example_115
1 of 14 in __main__.example_33
***Test Failed*** 2 failures.
Same failures were in rc0
Jaap
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0.rc1 released!
On May 28, 7:00 pm, John Cremona john.crem...@gmail.com wrote: 2009/5/28 Marshall Hampton hampto...@gmail.com: I had the same two numerical noise type failures in matrix2.pyx and expression.pyx, on an intel mac running 10.5. Those were the only failures. Same here on ubiuntu 32-bit. John Same for me (SuSE 32-bit). Note that one of the failures in expression.pyx is *not* numerical noise, it's a hash value -- presumably a 32/64 bit issue. David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 plan
Can I use this opportunity to request some reviews for modular forms patches? I decided I'd spend a few afternoons squashing as many easy modular forms buglets as I could, with the result that there is now a bunch of tickets that are [with patch, needs review]. It would be cool to get some of these into 4.0, since otherwise they will inevitably end up conflicting with stuff people do at SD15, and we all know how tedious it is to rebase patches. http://trac.sagemath.org/sage_trac/ticket/4337 http://trac.sagemath.org/sage_trac/ticket/4357 http://trac.sagemath.org/sage_trac/ticket/5262 http://trac.sagemath.org/sage_trac/ticket/5787 http://trac.sagemath.org/sage_trac/ticket/5792 (Craig's, not mine) http://trac.sagemath.org/sage_trac/ticket/5923 Regards, David On May 7, 2:49 am, mabshoff mabsh...@googlemail.com wrote: On May 6, 5:53 pm, William Stein wst...@gmail.com wrote: Hi, This is the plan for getting Sage-4.0 out. Help in any way you can. Wed May 6: * mhansen (by 2am) -- patches/todo list so anybody can help. * robertwb will have reviewed david roe's * mabshoff provides bill with symmetrica bug testcase *stand alone* testcase :) * mabshoff fix libtool issue for pynac I think Mike already partially fixed that, but we will see. Thu May 7: sage-4.0.alpha0.tar -- ecl; mop up positive review; freebsd burcin updated pynac (this will better test ecl) * wstein, robertwb, nick, mhansen -- help with pynac/symbolics doctest Fri May 8: sage-4.0.alpha1.tar -- mhansen's symbolics get in david roe's patch Sat May 9: Sage-4.0 day -- IRC /merge/referee: goal: coverage to 75.0%. E.g., * wstein or cwitty -- referee implicit plot 3d William will announce this separately later tonight. Sun May 10: sage-4.0.rc0.tar (feature freeze) * fix singular prompt issue (solaris fix) * fix other singular remaining issues. singular - solaris? Mon May 11: fix fallout; malb fix os x libsingular (?) Tue May 12: sage-4.0.rc1.tar Wed May 13: Thu May 14: sage-4.0.final.tar Fri May 15: Release sage-4.0.tar. During SD 15: Sage 4.0 release party :) -- William Stein Associate Professor of Mathematics University of Washingtonhttp://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Wrong answer in IntegerModRing.multiplicative_subgroups
On May 6, 7.10pm, William Stein wrote: Crap. Thanks for spotting this. Fortunately this is used in only one place in Sage; this one line in congroup_gamma0.py: return [GammaH(N, H) for H in R.multiplicative_subgroups()] Yes, that was how I noticed this -- my fix for 5250 caused multiplicative_subgroups to give a different answer when n = 2, which broke the doctest for that function in congroup_gamma0. On May 6, 7:13 pm, John Cremona john.crem...@gmail.com wrote: Do we have a function which returns (Z/NZ)* as an abelian group? Somehow secretly we do, because it's embedded in the DirichletGroup machinery; but nothing that explicitly creates an AbelianGroup object. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Wrong answer in IntegerModRing.multiplicative_subgroups
OK. In that case I'll upload a fix for #5250 without addressing this issue, and just fudge the multiplicative_subgroups method so it returns the same wrong output it did before, so the doctest in congroup_gamma0 passes. Once we have a new abelian groups framework based on #5882, someone can then go away and write a subgroups method for arbitrary abelian groups which gives correct output, and we can fix multiplicative_subgroups using that. David On May 6, 8:46 pm, William Stein wst...@gmail.com wrote: On Wed, May 6, 2009 at 12:13 PM, John Cremona john.crem...@gmail.com wrote: 2009/5/6 William Stein wst...@gmail.com: On Wed, May 6, 2009 at 11:33 AM, davidloeffler dave.loeff...@gmail.com wrote: On May 6, 7.10pm, William Stein wrote: Crap. Thanks for spotting this. Fortunately this is used in only one place in Sage; this one line in congroup_gamma0.py: return [GammaH(N, H) for H in R.multiplicative_subgroups()] Yes, that was how I noticed this -- my fix for 5250 caused multiplicative_subgroups to give a different answer when n = 2, which broke the doctest for that function in congroup_gamma0. On May 6, 7:13 pm, John Cremona john.crem...@gmail.com wrote: Do we have a function which returns (Z/NZ)* as an abelian group? Somehow secretly we do, because it's embedded in the DirichletGroup machinery; but nothing that explicitly creates an AbelianGroup object. Just some clarification. The functionality to do that is not embedded in the DirichletGroup machinery -- what's embedded is that the functionality is *used* there, so David knows it must be in Sage somewhere :-). Here's an example of how to get an explicit description of (Z/NZ)^* as a product of cyclic abelian groups: sage: R = Zmod(341) sage: R.unit_gens() [156, 34] sage: [a.multiplicative_order() for a in R.unit_gens()] [10, 30] sage: euler_phi(341) 300 Thus (Z/341Z)* = Z/10Z + Z/30Z with the map sending (1,0) to 156 and (0,1) to 34. OK, so if anyone did want to implement a class for multiplicative-group-mod-N then all the needed machinery is already there. I had tried r.tab ut had not see the unit_gens() function. Being able to work with abelian groups in all kinds of different arrangements and with subtle relations between them is one of the most critical and central tools needed in implementing computational number theory algorithms. That's why I've put a lot of work into http://trac.sagemath.org/sage_trac/ticket/5882lately. I did not know of that work, which looks very interesting (and will perhaps make AbelianGroup, as currently implemented, redundant?) Yes. The plan is that once 5882 is done (and optimized), then we'll implement abelian groups very easily as a light wrapper around the code at 5882. And finally, after long last, somebody will successfully (re)write abelian groups in Sage! -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.4.1.rc3 released
On Apr 16, 9:02 pm, Jaap Spies j.sp...@hccnet.nl wrote: On Fedora 9, 32 bit, after an upgrade: The following tests failed: sage -t devel/sage/sage/modular/dirichlet.py sage -t devel/sage/sage/misc/sagedoc.py On 32bit SuSE Linux, upgrading from 3.4.1.rc2, I also get the dirichlet.py error (and I get the same different answer that Jaap gets, 6.66133814775e-16 + 1.73205080757*I). I am not seeing the sagedoc.py error though. David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Doctesting weirdness
Never mind -- I remembered the existence of sage -t -verbose and found the problem. (It was because I had a comment in my file containing an unmatched opening triple quote -- this somehow throws out the doctest script's parser.) David On Apr 10, 12:03 pm, daveloeffler dave.loeff...@gmail.com wrote: I've been working on improving doctest coverage in the sage/modular directory, and I've hit a very curious problem. I added a new doctest to a file -- sage/modular/hecke/hecke_operator.py, if it matters -- and ran sage -t with the output line of the doctest blank, meaning to copy the correct output out of the test failure message. But it passed, and now I can't seem to get any doctests in this file to fail! Even if I insert random garbage into the code, it still passes sage -t. Other files that depend on this one fail; but this one still claims to work (even though if I run the tests from a Sage prompt they fail, as they should). Does anybody know how this can have happened? What could be making sage -t return All tests passed, when the file is deliberately totally broken? I've tried deleting all the temporary .doctest_foo.py files from SAGE_ROOT/tmp/, but that doesn't help. (It may be something to do with the fact that I had a sage -t * running for the whole sage/modular directory and I interrupted it with Ctrl-C; has that somehow left temporary files lying around that I should delete? If so, which ones?) David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: doctest coverage to 75%
On Apr 9, 9:45 am, William Stein wst...@gmail.com wrote: I hope those of you who feel qualified to write doctests, will help out. It's nearly impossible for one person to do all 1900 of those doctests in the next month. Writing doctests is not easy and it absolutely requires experience experience with the Sage library, and good understanding of the code you are testing. Thanks, I've had a look at the sage/modular directory, for which doctest coverage is 74.9% as of 3.4.1.rc1. OK, so this is perhaps one of the best-doctested parts already, but it's also one of the few I know much about. I've posted a patch at http://trac.sagemath.org/sage_trac/ticket/5727 which adds 28 new doctests (and fixes 2 small bugs) and adds another module to the reference manual. More to follow (maybe). David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: doctesting problems in 3.4.1.alpha0
On Mar 31, 2:19 pm, John Cremona john.crem...@gmail.com wrote: It works fine for me with an absolute path! John Me too. Thanks for the workaround, Georg! David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: smith normal form slow for a matrix over polynomial ring over GF(2)
On Mar 30, 8:24 pm, Christophe Oosterlynck tif...@gmail.com wrote: Hi, Consider matrices containing univariate polynomials over GF(2): is it normal that calculating the smith normal form for such a matrix is extremely slow? I wrote the smith_form code, and it's completely generic, applying to an arbitrary ring; at the time I was actually thinking mainly about matrices over the rings of integers of Euclidean quadratic fields. There are absolutely no optimised Smith form implementations specific to any rings except ZZ. That's why it's slow in your example. (I'm actually pleasantly surprised that it works at all.) David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.4.1.alpha0 released
I think I'm being credited with more than my fair share of reviewing here: #2551: Francis Clarke: __getitem__ for relative number field elements is ... surprising [Reviewed by John Cremona, David Loeffler] #5214: Francis Clarke: coercion to orders in relative number fields is not implemented [Reviewed by John Cremona, David Loeffler] #5276: Francis Clarke: bug in creating polynomial ring over some rings of integer [Reviewed by John Cremona, David Loeffler] #5508: Francis Clarke: Improvements for relative number fields [Reviewed by John Cremona, David Loeffler] I had nothing to do with any of this, save pointing out that fwclarke's patch fixes #4193 as well, which presumably gets me a reviewer credit for #4193 once that is closed; but I contributed nothing to reviewing the patch itself. BTW: sage -t devel/sage/sage/rings/number_field/ number_field_ideal_rel.py This issue is already in trac and has a patch that is part of a larger patch. That is my patch for #5159 -- improvements to Galois groups -- which has been 90% reviewed, positively, and just needs somebody to OK a trivial unpickling bugfix and few minor documentation changes for it to go in; this will provide some functionality that has been sought after since ancient times (ticket #133). David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Compiling the doc...
I also came across the problem with quaternion_order_ideal.py, but for me it went away when I re-built from a clean tarball (rather than upgrading from 3.4.rc0 as I had done before). But even the final 3.4 tarball generates some Sphinx error messages when you do a docbuild, from some slightly mis-formatted docstrings in quaternion_algebra.py. I've made a trac ticket for this -- #5531 -- and posted a patch. Any volunteers for a review? David On Mar 16, 6:52 pm, mabshoff mabsh...@googlemail.com wrote: On Mar 16, 11:43 am, Florent Hivert florent.hiv...@univ-rouen.fr wrote: It might be, but this is the error reported: OSError: [Errno 24] Too many open files Can you check with ulimit -a what your current limit is (it seems to be 1024 on sage.math for example) and increase it and try again? The sphinx build works for me with 256 max open files on OSX, so the limit itseself seems unlikely to be the culprit. Maybe you have some other code running on the box that leaks file handles? massena-*el/sage-main/doc $ ulimit -a -t: cpu time (seconds) unlimited -f: file size (blocks) unlimited -d: data seg size (kbytes) unlimited -s: stack size (kbytes) 8192 -c: core file size (blocks) 0 -m: resident set size (kbytes) unlimited -u: processes 268288 -n: file descriptors 1024 -l: locked-in-memory size (kb) 32 -v: address space (kb) unlimited -x: file locks unlimited -i: pending signals 268288 -q: bytes in POSIX msg queues 819200 -e: max nice 0 -r: max rt priority 0 massena-*el/sage-main/doc $ ulimit -n 1025 ulimit: value exceeds hard limit I can't give it more... Ok. Is there a way to know it some process leaks file handles ? From a regular account / from root ? I tried lsof but it only answered my file 192 of them (I don't have a root account). I am not aware of anything in Sage that leaks file handles but the gmp- ecm interface at the moment. It seems that the issue pops up when building the LaTeX bits of the documentation, so building the doc via sage -docbuild --jsmath all html i.e. using jsmath might work around the problem. Cheers, Florent Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: missing sphinxification
There seem to be *hundreds* of files missing from the new reference manual. I did a grep: da...@groke:~/sage-3.4.rc0/devel/sage-main/sage grep EXAMPL.*[^:]:$ -lr * to pick up files that contained EXAMPLES: with a single colon rather than a double one, and it turned up no fewer than 510 files! Some of these, e.g. algebras/steenrod_algebra.py, are fine -- they just have examples subdivided into smaller groups within a docstring -- but of the 10 or so files I looked at, the other 9 were all rogue. In particular, large parts of the number fields code have no entries in the reference manual, and nor do group algebras, Kodaira symbols, Galois groups... Checking in 3.3, it seems that these files were never linked into the reference manual in the first place; but is there ever any good reason why a file that has docstrings should be excluded from the manual? David On Mar 6, 8:30 am, YannLC yannlaiglecha...@gmail.com wrote: Hi, I think /sage/group/generic.py docstrings have not been changed. Cheers --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
