[sage-devel] sage-2.8.5
Hi, SAGE 2.8.5 has been released at http://sagemath.org/. This is a *MAJOR* new Sage release, which includes many bugfixes (some quite important to usability), and substantial new features and functionality. Sage 2.8.5 includes Mike Hansen's massive new combinatorics packages along with the Symmetrica C library, much new multivariate polynomial code by Martin Albrecht along with bug fixes and sparse mod-p linear algebra via Linobx, new algebraic number fields code by William Stein and Robert Bradshaw, a major refactoring of NTL by Joel Mohler, Craig Citro, David Harvey and Robert Bradshaw, Bill Hart and David Harvey's the long-awaited FLINT library for super-fast polynomial arithmetic is now included standard in SAGE (though currently it is not used by anything by default, and can only multiply polynomials), a very nice new global proof option by David Roe, Robert Bradshaw's complete and fully optimized implementation of sequence notation [1..5], (2..7), [1,3,5,..19], and updates to MPFR, IML, and Linbox thanks to Michael Abshoff and Martin Albrecht. PPC32 Linux should now also be officially supported (thanks to Michael Abshoff). John Cremona also updated mwrank. Finally, Gonzalo Tornaria and William Stein fixed a major bug in the Sage signal handling system, so control-c, should now be much more robust. We closed 43 tickets, which are listed here: http://trac.sagemath.org/sage_trac/query?status=closedmilestone=sage-2.8.5order=id or, by category, here: http://trac.sagemath.org/sage_trac/milestone/sage-2.8.5 Thanks to the many people who contributed to this release, and anybody I forgot to mention above. There were dozens of people not listed above who made important contributions. NOTE: Since this is such a major release, there will likely be problems and a 2.8.5.1 release shortly to fix them. Please report! -- William Stein Associate Professor of Mathematics University of Washington http://wstein.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: Fwd: [sage-devel] Regarding range and '..' operator
For what it's worth, I too am against using either form of open-ended interval notation such as [a,b), [a,b[ and so on. Let's keep brackets matching; both those notations are used in Mathematics (the latter mainly in the French world), but *only* for intervals of reals where it is necessary. I cannot see why anyone would want to write (0..10) to mean the same as [1..9], i.e. [1,2,3,4,5,6,7,8,9]. But the use of .. for *inclusive* ranges does seem very natural to me, despite not being in Pyuthon proper, and I would agree with Peter Doyle's remarks on that for undergraduate teaching. [Aside: Peter, does Dartmouth still teach BASIC to all undergratuates (in all majors) like they did when I was there 1982-84? That was when Kemeny was still revered by all, and part of te requirement was that every single undergrad had to watch the 2-part video of Kemeny explaining BASIC programming.] John On 9/20/07, William Stein [EMAIL PROTECTED] wrote: -- Forwarded message -- From: Peter Doyle [EMAIL PROTECTED] Date: Sep 20, 2007 9:04 AM Subject: Re: [sage-devel] Regarding range and '..' operator To: William Stein [EMAIL PROTECTED] Hi William, I am glad you have not abandoned your suggestion of introducing the 1..10 notation, which I think is absolutely brilliant. I am new to Python, and while I am not 100% keen on it, I do appreciate the clean, simple syntax. From long experience using computers in undergrad courses, I understand that there are great benefits to being able to tell at a glance what a (simple) program is supposed to do. Unless programming is the subject of the course, there is no time to spare for semicolons and underscores. if I want students to be able to modify existing programs, and write simple programs of their own, the language has to be simple, in a way that Python mostly is. If I'm going to use SAGE in a probability course, it will be a huge advantage to have this simple, crystal clear syntax for loops, conditionals, function definitions. Students are going to know at a glance how simple demo programs work. Except for the problem with range(). But if I can write for i in 1..10 instead of for i in xrange(1,11) then we'll be golden. Well, until we crash into other peculiarities of Python, like the way I can accidentally redefine the default value of a list argument, or otherwise accidentally modifiy an argument passed by reference. But that's way down the road, and we'll likely not run into that in a probability course or a calculus course. Cheers, Peter Cheers, Peter -- William Stein Associate Professor of Mathematics University of Washington http://wstein.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: LLL
Implementing LLL well is a black art. I don't know enough to know why the Magma one is so much better, but at least part of the reason may be that the experts in LLL are using Magma for their development work. Hence, once everyone in te world uses Sage, ... Thanks for wrapping NTL's LLL. But NTL only has integer LLL, where the input is a basis for the lattice in Z^n, while for some applications it is also useful to have a version which takes as input the Gram matrix over R (i.e. any positive definite symmetric real matrix). For example that is what is useful for reducing bases of elliptic curves. Pari has that but NTL does not. John On 9/21/07, Martin Albrecht [EMAIL PROTECTED] wrote: Hi everyone, SAGE 2.8.5 finally adds a method for LLL lattice reduction to the Matrix_integer_dense class. For now it only wraps NTL but we actually have two more implementations available in SAGE which are to be wrapped conveniently soon. However, as ticket http://trac.sagemath.org/sage_trac/ticket/723 points out, they are all blown away by MAGMA. sage: a = random_matrix(ZZ,200) sage: time b=a.lll() # NTL, delta = 3/4 CPU times: user 10.63 s, sys: 0.03 s, total: 10.66 s Wall time: 10.67 sage: m = magma(a) sage: time b = m.LLL() # MAGMA, delta = 3/4 CPU times: user 0.00 s, sys: 0.00 s, total: 0.00 s Wall time: 1.72 sage: p = pari(a) sage: time b = p.qflll(1) # Pari CPU times: user 10.47 s, sys: 0.03 s, total: 10.51 s Wall time: 10.61 sage: g = gap(a) sage: time b = g.LLLReducedBasis() # GAP killed after two minutes The relevant MAGMA documentation is at http://www.msri.org/about/computing/docs/magma/html/text833.htm The relevant PARI documentation is at http://pari.math.u-bordeaux.fr/dochtml/html.stable/Vectors,_matrices,_linear_algebra_and_sets.html#qflll The relevant NTL documentation is at: http://www.shoup.net/ntl/doc/LLL.txt Also, Google came up with http://www.math.uu.nl/people/vdkallen/lllimplementations.html which could be relevant or not, I don't know. The point of this mail is to ask you -- dear LLL wizards -- (a) why Magma is so much faster and (b) what we can do about it. 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] -- 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-support] sage-2.8.5
William Stein wrote: Hi, SAGE 2.8.5 has been released at http://sagemath.org/. NOTE: Since this is such a major release, there will likely be problems and a 2.8.5.1 release shortly to fix them. Please report! Builds on Fedora 7, -- The following tests failed: sage -t devel/sage-main/sage/combinat/skew_tableau.py sage -t devel/sage-main/sage/combinat/ribbon.py Total time for all tests: 1838.3 seconds [EMAIL PROTECTED] sage-2.8.5]$ See below. Jaap [EMAIL PROTECTED] sage-2.8.5]$ ./sage -t devel/sage-main/sage/combinat/skew_tableau.py sage -t devel/sage-main/sage/combinat/skew_tableau.py ** File skew_tableau.py, line 234: sage: SkewTableau([[None, 2], [1, 3]]).is_standard() Expected: True Got: False ** File skew_tableau.py, line 290: sage: SkewTableau([[None,1],[2],[3]]).restrict(2) Exception raised: Traceback (most recent call last): File /home/jaap/downloads/sage-2.8.5/local/lib/python2.5/doctest.py, line 1212, in __run compileflags, 1) in test.globs File doctest __main__.example_16[0], line 1, in module SkewTableau([[None,Integer(1)],[Integer(2)],[Integer(3)]]).restrict(Integer(2))###line 290: sage: SkewTableau([[None,1],[2],[3]]).restrict(2) File /home/jaap/downloads/sage-2.8.5/local/lib/python2.5/site-packages/sage/combinat/skew_tableau.py, line 297, in restrict raise ValueError, the skew tableau must be standard to perform the restriction ValueError: the skew tableau must be standard to perform the restriction ** File skew_tableau.py, line 292: sage: SkewTableau([[None,1],[2],[3]]).restrict(1) Exception raised: Traceback (most recent call last): File /home/jaap/downloads/sage-2.8.5/local/lib/python2.5/doctest.py, line 1212, in __run compileflags, 1) in test.globs File doctest __main__.example_16[1], line 1, in module SkewTableau([[None,Integer(1)],[Integer(2)],[Integer(3)]]).restrict(Integer(1))###line 292: sage: SkewTableau([[None,1],[2],[3]]).restrict(1) File /home/jaap/downloads/sage-2.8.5/local/lib/python2.5/site-packages/sage/combinat/skew_tableau.py, line 297, in restrict raise ValueError, the skew tableau must be standard to perform the restriction ValueError: the skew tableau must be standard to perform the restriction ** File skew_tableau.py, line 307: sage: SkewTableau([[None,1],[2],[3]]).to_chain() Exception raised: Traceback (most recent call last): File /home/jaap/downloads/sage-2.8.5/local/lib/python2.5/doctest.py, line 1212, in __run compileflags, 1) in test.globs File doctest __main__.example_17[0], line 1, in module SkewTableau([[None,Integer(1)],[Integer(2)],[Integer(3)]]).to_chain()###line 307: sage: SkewTableau([[None,1],[2],[3]]).to_chain() File /home/jaap/downloads/sage-2.8.5/local/lib/python2.5/site-packages/sage/combinat/skew_tableau.py, line 311, in to_chain raise ValueError, the skew tableau must be standard to convert to a chain ValueError: the skew tableau must be standard to convert to a chain ** 3 items had failures: 1 of 4 in __main__.example_14 2 of 2 in __main__.example_16 1 of 1 in __main__.example_17 ***Test Failed*** 4 failures. For whitespace errors, see the file .doctest_skew_tableau.py [1.5 s] exit code: 256 [EMAIL PROTECTED] sage-2.8.5]$ ./sage -t devel/sage-main/sage/combinat/ribbon.py sage -t devel/sage-main/sage/combinat/ribbon.py ** File ribbon.py, line 82: sage: Ribbon([[2,3],[1,4,5]]).is_standard() Expected: True Got: False ** 1 items had failures: 1 of 3 in __main__.example_5 ***Test Failed*** 1 failures. For whitespace errors, see the file .doctest_ribbon.py [1.5 s] exit code: 256 --~--~-~--~~~---~--~~ 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] irange ticket #706 wontfix
William, I'm sorry to see that irange is not in sage-2.8.5. Your comment: I think http://trac.sagemath.org/sage_trac/ticket/702 is actually much nicer to use, so for now I think irange isn't needed. is not quite to the point. irange can take three arguments: start, stop and step. The arguments are not restricted to integers. See the examples I give. Moreover I think irange is more Pythonic! As irange is based only on srange it will be fast now tick #701 is closed. Arguments enough to reopen ticket #706, I think. Jaap sage: v = irange(0,5); v [0, 1, 2, 3, 4, 5] sage: v = irange(1,10); v [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] sage: v = irange(10,-1,-1); v [10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0, -1] sage: v = irange(1,8, 1/2); v [1, 3/2, 2, 5/2, 3, 7/2, 4, 9/2, 5, 11/2, 6, 13/2, 7, 15/2, 8] sage: v = irange(1,2, 0.4); v [1, 1.40, 1.80] sage: v = irange(1, 2, 0.5); v [1, 1.50, 2] sage: v = irange(1, 2, -0.5); v [] sage: v = irange(2, -2, -0.5); v [2, 1.50, 1.00, 0.500, 0.000, -0.500, -1.00, -1.50, -2] sage: v = irange(10,1); v [] sage: v = irange(10,10); v [10] sage: v = irange(10); v Traceback (most recent call last): ... TypeError: irange() takes at least 2 arguments (1 given) sage: v = irange(0.5, 2.5, 0.5); v [0.500, 1.00, 1.50, 2.00, 2.50] sage: [n^2 for n in irange(-1, 10)] [1, 0, 1, 4, 9, 16, 25, 36, 49, 64, 81, 100] And this one from the calculus thread! -- I think that the Python convention of not including the upper bound in a sum is a real problem. sage: sum(i for i in range(1,10)) 45 I understand this is a fundamental convention in Python, and that it is very natural for people used to malloc(), but I worry that this will be a constant headache for students (and professors!). sage: sum(i for i in irange(1, 10)) 55 --~--~-~--~~~---~--~~ 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] srange issue
The new (fast) srange function with include_endpoint=True dus not include the endpoint in some cases: sage: srange(1.0, 5.0, include_endpoint=True) [1.00, 2.00, 3.00, 4.00] Jaap --~--~-~--~~~---~--~~ 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: irange ticket #706 wontfix
Some timings: in sage-2.8.4.2 with patch: sage: %time sage: for i in range(1000): ... v = irange(0, i) CPU time: 8.72 s, Wall time: 11.83 s in sage-2.8.5 with patch it looks much better: sage: %time sage: for i in range(1000): ... v = irange(0, i) CPU time: 0.33 s, Wall time: 0.33 s sage: %time sage: for i in range(1000): ... v = [0..i] CPU time: 0.40 s, Wall time: 0.40 s sage: %time sage: for i in [0..1000]: ... v = [0..i] CPU time: 0.39 s, Wall time: 0.39 s sage: %time sage: for i in srange(1000): ... v = irange(0, i) CPU time: 0.31 s, Wall time: 0.33 s Cheers, Jaap --~--~-~--~~~---~--~~ 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: LLL
On 9/21/07, Martin Albrecht [EMAIL PROTECTED] wrote: On Friday 21 September 2007, David Kohel wrote: Since LLL and LLLGram in Magma V2.13 are written by Damien Stehle, using his asymptotically better algorithm. The previous version was not even mathematically correct (adhoc improvements or post-processing could destroy the LLL reduction condition). Damien provides C code under GPL and can be found on his web page: http://perso.ens-lyon.fr/damien.stehle/english.html It might take some art to decide on optimal parameters, but linking it into SAGE should provide the same asymptotic performance as in Magma. --David Thanks! From what I can see it is probably best to: (first) try the FP variants of NTL's LLL first (I overlooked those before) These use real arithmetic internally, I think, but do not alow real input data as in my previous posting. (then) try Damien's fast.c implementation, also the proved version seems interesting, given the discussions on this list. Certainly! This would be very good. John 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] -- 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: LLL
(first) try the FP variants of NTL's LLL first (I overlooked those before) These use real arithmetic internally, I think, but do not alow real input data as in my previous posting. Yes, it seems so. I am not very familiar with GP/Pari, which function implements what you want (gflllgram)? It is probably quite easy to wrap it for you once I know what to call. 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: [sage-support] Re: sage-2.8.5
Something funny on mac os 10.4.10, core 2 duo On a clean build of sage 2.8.5. When I run sage -testall it basically freezes when it gets to Testing SAGE constructions guide. It just sits there permanently; top reports the CPU is basically idle. But when I do sage -testall -verbose, then it gets through the constructions guide with no problems, in about 30 seconds! david --~--~-~--~~~---~--~~ 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] documentation changes
I changed some of the documentation in graphs/graph.py (formatted it using Latex). How do I build a new manual to see my changes? Going to the doc directory and typing make pdf seems to just pick up the old sage.graphs.graph.tex file and not generate a new one from the python source. Did I miss something in the documentation? Thanks, Jason --~--~-~--~~~---~--~~ 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: srange issue
On Sep 21, 2007, at 10:29 AM, Hamptonio wrote: The relevant codeblock from misc/misc.py is: if include_endpoint: if universe in [int, long, ZZ]: if (start-end) % step == 0: end += step elif (start-end)/step in ZZ: end += step which looks a little funny to me in general; in this specific case of course universe=None and (start-end)/step is a RealNumber so the endpoint is left unchanged. I'm not sure what would be wrong with just having if include_endpoint: end += step but maybe the author (William S. or Robert B.?) had a reason I can't think of. This is because srange(1,10,2) shouldn't include 10 whether or not include_endpoint is true. It's a question of landing exactly on the endpoint (thought the above code is wrong because floats are never in ZZ, so I've just done int(x) == x. I have also neglected (so far) to handle a couple of other cases (e.g. when elements are uncomparable but (start-end)/step is still an int like for CC). - Robert -Marshall On Sep 21, 7:59 am, Jaap Spies [EMAIL PROTECTED] wrote: The new (fast) srange function with include_endpoint=True dus not include the endpoint in some cases: sage: srange(1.0, 5.0, include_endpoint=True) [1.00, 2.00, 3.00, 4.00] Jaap --~--~-~--~~~---~--~~ 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: srange issue
Fix up at http://sagemath.org:9002/sage_trac/ticket/701 - Robert On Sep 21, 2007, at 10:43 AM, Jaap Spies wrote: Robert Bradshaw wrote: I've fixed this (patch forthcoming). I don't think we can do something that always does the right thing for floating points though, as sage: sum([1.1]*10) 11 True sage: sum([1.3]*10) 13 True This is NOT a bug in Sage so much as an artifact of the way computers store floating point numbers. Now, with the decimal literal thing that I was toying with, perhaps we could do accurate sranges anyways. - Robert Yes. That is evident, but in my simple example the endpoint should be included. On Sep 21, 2007, at 6:59 AM, Jaap Spies wrote: The new (fast) srange function with include_endpoint=True dus not include the endpoint in some cases: sage: srange(1.0, 5.0, include_endpoint=True) [1.00, 2.00, 3.00, 4.00] Jaap Jaap --~--~-~--~~~---~--~~ 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: documentation changes
On 9/21/07, William Stein [EMAIL PROTECTED] wrote: On 9/21/07, Jason Grout [EMAIL PROTECTED] wrote: I changed some of the documentation in graphs/graph.py (formatted it using Latex). How do I build a new manual to see my changes? cd SAGE_ROOT/devel/doc/ref ./build_pdf That will create ref.pdf, which you can view. This *requires* that you have latex2html correctly installed, which -- due to its screwy license -- often isn't installed on machines by default. Would this method also work for docstrings files which are not included in the reference manual? (Ie, for newly created *.py files.) Going to the doc directory and typing make pdf seems to just pick up the old sage.graphs.graph.tex file and not generate a new one from the python source. That would also work, but you have to first do ./update in the SAGE_ROOT/devel/doc/ref/ directory. Did I miss something in the documentation? No, you didn't miss anything, since the build system is unfortunately not really documented. There is a minimal README.txt in SAGE_ROOT/devel/doc/ref/ If anybody understands the build system and wants to document the above sort of thing, please post a patch to trac against the doc repository. 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: irange ticket #706 wontfix
On Sep 21, 2007, at 5:40 AM, Jaap Spies wrote: William, I'm sorry to see that irange is not in sage-2.8.5. Your comment: I think http://trac.sagemath.org/sage_trac/ticket/702 is actually much nicer to use, so for now I think irange isn't needed. is not quite to the point. irange can take three arguments: start, stop and step. The arguments are not restricted to integers. So can the other range functions we have. See the examples I give. Moreover I think irange is more Pythonic! I think the fact that irange looks so much like range is actually a disadvantage because they act so different (I consider potentially returning an extra item a significant difference, especially since the presence of that extra item is sensitively dependent on (end- start) % step.) I would be in favor of shortening srange(..., include_endpoint=True) to srange(endpoint=True). In trying out your examples, I realized a shortcoming with the new notation though. First, sometimes it's more convenient to give a step rather than a second item. What would people think about the notation [start .. end ; step] Also, [10..1] now returns [10], it should probably return the empty list. What about [10,11,.,0]? Also the empty list? I think so. Thoughts? As irange is based only on srange it will be fast now tick #701 is closed. Arguments enough to reopen ticket #706, I think. I don't think so, especially after resolving the issues above, but the two of us are probably equally bias about or own pieces of code. The only other person to have spoken up is William, maybe we should consider re-opening it if others speak up. - Robert Examples: sage: v = irange(0,5); v [0, 1, 2, 3, 4, 5] sage: v = [0..5]; v [0, 1, 2, 3, 4, 5] sage: v = irange(1,10); v [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] sage: v = [1..10]; v [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] sage: v = irange(10,-1,-1); v [10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0, -1] sage: v = [10,9,..,-1]; v [10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0, -1] sage: v = irange(1,8, 1/2); v [1, 3/2, 2, 5/2, 3, 7/2, 4, 9/2, 5, 11/2, 6, 13/2, 7, 15/2, 8] sage: v = [1, 3/2, .., 8]; v [1, 3/2, 2, 5/2, 3, 7/2, 4, 9/2, 5, 11/2, 6, 13/2, 7, 15/2, 8] sage: v = irange(1,2, 0.4); v [1, 1.40, 1.80] sage: v = [1,1.4,..,2]; v [1.00, 1.40, 1.80] sage: v = irange(1, 2, 0.5); v [1, 1.50, 2] sage: v = [1,1.5,..,2]; v [1.00, 1.50, 2.00] sage: v = irange(1, 2, -0.5); v [] sage: v = [1,.5,..,2]; v # this is different because it computes the range 0.5 to 2 (with step -0.5) after appending the first items to the list. Bug? [1.00, 0.500] sage: v = irange(2, -2, -0.5); v [2, 1.50, 1.00, 0.500, 0.000, -0.500, -1.00, -1.50, -2] sage: [2,1.5,..,-1.5] [2, 1.50, 1.00, 0.500, 0.000, -0.500, -1.00, -1.50, -2] sage: v = irange(10,1); v [] sage: [10,..,1] [10] sage: v = irange(10,10); v [10] sage: v = irange(10); v Traceback (most recent call last): ... TypeError: irange() takes at least 2 arguments (1 given) sage: v = irange(0.5, 2.5, 0.5); v [0.500, 1.00, 1.50, 2.00, 2.50] sage: [0.5,1,..,2.5] [0.500, 1.00, 1.50, 2.00, 2.50] sage: [n^2 for n in irange(-1, 10)] [1, 0, 1, 4, 9, 16, 25, 36, 49, 64, 81, 100] sage: [n^2 for n in [-1..10]] [1, 0, 1, 4, 9, 16, 25, 36, 49, 64, 81, 100] sage: [n^2 for n in (-1..10)] # as a generator [1, 0, 1, 4, 9, 16, 25, 36, 49, 64, 81, 100] And this one from the calculus thread! -- I think that the Python convention of not including the upper bound in a sum is a real problem. sage: sum(i for i in range(1,10)) 45 I understand this is a fundamental convention in Python, and that it is very natural for people used to malloc(), but I worry that this will be a constant headache for students (and professors!). sage: sum(i for i in irange(1, 10)) 55 sage: sum(1..10) 55 --~--~-~--~~~---~--~~ 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: documentation changes
On 9/21/07, Jason Grout [EMAIL PROTECTED] wrote: Thanks for your replies! I'm now able to build the documentation and get my changes into my version of the reference manual. As for reference material, I consider the reference manual the comprehensive unabridged dictionary of SAGE. You know, something you could curl up on a couch with on a rainy day :). I'd love to see it expand to twice its size if the documentation is there. Same here. Also, an observation: I updated the reference tex files by doing: cd /sage/devel/doc/ref/ ./update cd .. make pdf However, it claimed that there was nothing to be done, since everything was up to date. I had to make clobber before it would build the documentation again. Is there a way to have the ./update command touch a file which was then a dependency for the make pdf/html/etc commands? That way, running ./update would force make to rerun the pdf/html/etc generation. I'll open up a trac ticket. If this suggestion is a bad idea, feel free to close the ticket. The main reason for ./build_pdf or ./build_dvi was that I couldn't figure out how to do exactly what you suggest above reliably.If somebody can figure it out, that would be appreciated. Incidentally, the whole sage documentation structure started from the Python documentation (probably Python 2.4), which I just motivated to be the Sage manuals instead. I had experimented a lot with automated tools like epydoc, etc., and found that they break a lot on the incredibly complicated Sage library, they don't play well with Cython code (which is nearly 1/3rd of Sage?), and and they just don't feel as well organized and readable as something that a person has to spend time putting together. The current documentation -- though not comprehensive -- tends to only have things in it that are reasonably usable and stable, so the stuff that epydoc would pick up that is really a mess isn't there. That said, *pydoc has probably improved a lot in the last 2 years (since I last used it), and it would be good to have some 100% complete autogenerated variant of the reference manual in addition to the current more manually organized one. 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: documentation changes
William Stein wrote: On 9/21/07, David Joyner [EMAIL PROTECTED] wrote: On 9/21/07, William Stein [EMAIL PROTECTED] wrote: On 9/21/07, Jason Grout [EMAIL PROTECTED] wrote: I changed some of the documentation in graphs/graph.py (formatted it using Latex). How do I build a new manual to see my changes? cd SAGE_ROOT/devel/doc/ref ./build_pdf That will create ref.pdf, which you can view. This *requires* that you have latex2html correctly installed, which -- due to its screwy license -- often isn't installed on machines by default. Would this method also work for docstrings files which are not included in the reference manual? (Ie, for newly created *.py files.) No, this will certainly not work for such docstrings -- I would like something that does. This should be put into a trac ticket. By the way, you *can* simply add the new file by making an empty file with the right now (but replace _ by -). Then include it in ref.tex. There is actually now a massive amount of code that has lots of documentation but isn't in the reference manual. This needs to change. Of course, then the reference manual will go from 2,200 pages to 4,000 pages... Thanks for your replies! I'm now able to build the documentation and get my changes into my version of the reference manual. As for reference material, I consider the reference manual the comprehensive unabridged dictionary of SAGE. You know, something you could curl up on a couch with on a rainy day :). I'd love to see it expand to twice its size if the documentation is there. Also, an observation: I updated the reference tex files by doing: cd /sage/devel/doc/ref/ ./update cd .. make pdf However, it claimed that there was nothing to be done, since everything was up to date. I had to make clobber before it would build the documentation again. Is there a way to have the ./update command touch a file which was then a dependency for the make pdf/html/etc commands? That way, running ./update would force make to rerun the pdf/html/etc generation. I'll open up a trac ticket. If this suggestion is a bad idea, feel free to close the ticket. Thanks, Jason --~--~-~--~~~---~--~~ 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: irange ticket #706 wontfix
On Sep 21, 2007, at 12:27 PM, Jason Grout wrote: Does your patch take care of this? sage: [1.2..3.5] [1.20, 2.20, 3.20, 4.20] Yes, now sage: [1.2..3.5] [1.20, 2.20, 3.20] --~--~-~--~~~---~--~~ 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: irange ticket #706 wontfix
On 9/21/07, Robert Bradshaw [EMAIL PROTECTED] wrote:
On Sep 21, 2007, at 5:40 AM, Jaap Spies wrote:
irange can take three arguments: start, stop and step.
The arguments are not restricted to integers.
So can the other range functions we have.
See the examples I give. Moreover I think irange is more Pythonic!
I think the fact that irange looks so much like range is actually a
disadvantage because they act so different (I consider potentially
[...]
start) % step.) I would be in favor of shortening srange(...,
include_endpoint=True) to srange(endpoint=True).
That's a great idea.
In trying out your examples, I realized a shortcoming with the new
notation though. First, sometimes it's more convenient to give a step
rather than a second item. What would people think about the notation
[start .. end ; step]
That might be OK. I would like to wait at least a month and let
people get some sense of how [start .. end] feels in practice, i.e.,
let the dust settle, before consider the above for inclusion.
Feedback would be good though. This [start .. end] notation
is really just supposed to be a simple shorthand, not a be-all,
end all.
Also, [10..1] now returns [10], it should probably return the empty
list.
It should *definitely* return the empty list; that is what
Magma does:
sage: magma.eval('[10..1]')
'[]'
What about [10,11,.,0]? Also the empty list? I think so. Thoughts?
No clue. That scares me.
As irange is based only on srange it will be fast now tick #701 is
closed.
Arguments enough to reopen ticket #706, I think.
I don't think so, especially after resolving the issues above, but
the two of us are probably equally bias about or own pieces of code.
The only other person to have spoken up is William, maybe we should
consider re-opening it if others speak up.
I am biased against irange because there is already:
range, xrange, srange, and xsrange,
and the argumetn for irange is to *lesson* confusion.
Having irange will mean also having xirange, and that's
just too many ranges for my brain.
Examples:
sage: v = irange(0,5); v
[0, 1, 2, 3, 4, 5]
sage: v = [0..5]; v
[0, 1, 2, 3, 4, 5]
sage: v = irange(1,10); v
[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
sage: v = [1..10]; v
[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
sage: v = irange(10,-1,-1); v
[10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0, -1]
sage: v = [10,9,..,-1]; v
[10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0, -1]
sage: v = irange(1,8, 1/2); v
[1, 3/2, 2, 5/2, 3, 7/2, 4, 9/2, 5, 11/2, 6, 13/2, 7, 15/2, 8]
sage: v = [1, 3/2, .., 8]; v
[1, 3/2, 2, 5/2, 3, 7/2, 4, 9/2, 5, 11/2, 6, 13/2, 7, 15/2, 8]
sage: v = irange(1,2, 0.4); v
[1, 1.40, 1.80]
sage: v = [1,1.4,..,2]; v
[1.00, 1.40, 1.80]
sage: v = irange(1, 2, 0.5); v
[1, 1.50, 2]
sage: v = [1,1.5,..,2]; v
[1.00, 1.50, 2.00]
sage: v = irange(1, 2, -0.5); v
[]
sage: v = [1,.5,..,2]; v # this is different because it computes the
range 0.5 to 2 (with step -0.5) after appending the first items to
the list. Bug?
[1.00, 0.500]
sage: v = irange(2, -2, -0.5); v
[2, 1.50, 1.00, 0.500,
0.000, -0.500, -1.00,
-1.50, -2]
sage: [2,1.5,..,-1.5]
[2, 1.50, 1.00, 0.500,
0.000, -0.500, -1.00,
-1.50, -2]
sage: v = irange(10,1); v
[]
sage: [10,..,1]
[10]
sage: v = irange(10,10); v
[10]
sage: v = irange(10); v
Traceback (most recent call last):
...
TypeError: irange() takes at least 2 arguments (1 given)
sage: v = irange(0.5, 2.5, 0.5); v
[0.500, 1.00, 1.50,
2.00, 2.50]
sage: [0.5,1,..,2.5]
[0.500, 1.00, 1.50,
2.00, 2.50]
sage: [n^2 for n in irange(-1, 10)]
[1, 0, 1, 4, 9, 16, 25, 36, 49, 64, 81, 100]
sage: [n^2 for n in [-1..10]]
[1, 0, 1, 4, 9, 16, 25, 36, 49, 64, 81, 100]
sage: [n^2 for n in (-1..10)] # as a generator
[1, 0, 1, 4, 9, 16, 25, 36, 49, 64, 81, 100]
And this one from the calculus thread!
-- I think that the Python convention of not including the upper
bound
in a sum is a real problem.
sage: sum(i for i in range(1,10))
45
I understand this is a fundamental convention in Python, and
that it is
very
natural for people used to malloc(), but I worry that this will
be a
constant
headache for students (and professors!).
sage: sum(i for i in irange(1, 10))
55
sage: sum(1..10)
55
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL
[sage-devel] Re: irange ticket #706 wontfix
Robert Bradshaw wrote: On Sep 21, 2007, at 5:40 AM, Jaap Spies wrote: Your comment: I think http://trac.sagemath.org/sage_trac/ticket/702 is actually much nicer to use, so for now I think irange isn't needed. is not quite to the point. irange can take three arguments: start, stop and step. The arguments are not restricted to integers. So can the other range functions we have. Sure, that is why they exists. But there are strange side effects in [a..b]. My last example has an educational impact: See the calculus thread. See the examples I give. Moreover I think irange is more Pythonic! I think the fact that irange looks so much like range is actually a disadvantage because they act so different (I consider potentially returning an extra item a significant difference, especially since the presence of that extra item is sensitively dependent on (end- start) % step.) I would be in favor of shortening srange(..., include_endpoint=True) to srange(endpoint=True). Looking like range: xrange, srange, xsrange, sxrange, Ellipsis. In a few years with Python 3k xrange and family will be obsolete. I still find having a function irange is more Pythonic. Maybe you should formulate a PEP for inclusion of the '..' operator for inclusion in Python 3.x! In trying out your examples, I realized a shortcoming with the new notation though. First, sometimes it's more convenient to give a step rather than a second item. What would people think about the notation [start .. end ; step] This is the equivalent of irange(start, end, stop), I soppose? Also, [10..1] now returns [10], it should probably return the empty list. What about [10,11,.,0]? Also the empty list? I think so. Thoughts? [10,11,.,0] ?? As irange is based only on srange it will be fast now tick #701 is closed. Arguments enough to reopen ticket #706, I think. I don't think so, especially after resolving the issues above, but the two of us are probably equally bias about or own pieces of code. Yes, but I think there arguments enough to add a function irange or equivalent with a better name! Indeed, I'm not a fan of the a..b notation. It reminds me to much to Maple, where there is no alternative step argument. The only other person to have spoken up is William, maybe we should consider re-opening it if others speak up. Jaap --~--~-~--~~~---~--~~ 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: LLL
On 9/21/07, David Kohel [EMAIL PROTECTED] wrote: Since LLL and LLLGram in Magma V2.13 are written by Damien Stehle, using his asymptotically better algorithm. The previous version was not even mathematically correct (adhoc improvements or post-processing could destroy the LLL reduction condition). Damien provides C code under GPL and can be found on his web page: http://perso.ens-lyon.fr/damien.stehle/english.html It might take some art to decide on optimal parameters, but linking it into SAGE should provide the same asymptotic performance as in Magma. David, many thanks for pointing this out!! It's extremely interesting. I hope somebody (e.g., Martin?) can build Damien's code and do some benchmarks very soon. -- 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: LLL
I hope somebody (e.g., Martin?) can build Damien's code and do some benchmarks very soon. Right now I am wrapping NTL's FP variants. The reason NTL was beaten so badly is because MAGMA uses FP variants while NLT's LLL uses exact arithmetic. However, MAGMA can do FP by default, because they have a proveable FP implementation (via Damien). So I am wrapping the NTL stuff first and see how fast we are. Then I'll take a look at Damien's stuff. Btw. If a user deliberately chooses LLL_FP and the global proof == True, shall we raise an exception? 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: irange ticket #706 wontfix
Robert Bradshaw wrote: On Sep 21, 2007, at 5:40 AM, Jaap Spies wrote: William, I'm sorry to see that irange is not in sage-2.8.5. Your comment: I think http://trac.sagemath.org/sage_trac/ticket/702 is actually much nicer to use, so for now I think irange isn't needed. is not quite to the point. irange can take three arguments: start, stop and step. The arguments are not restricted to integers. So can the other range functions we have. See the examples I give. Moreover I think irange is more Pythonic! I think the fact that irange looks so much like range is actually a disadvantage because they act so different (I consider potentially returning an extra item a significant difference, especially since the presence of that extra item is sensitively dependent on (end- start) % step.) I would be in favor of shortening srange(..., include_endpoint=True) to srange(endpoint=True). In trying out your examples, I realized a shortcoming with the new notation though. First, sometimes it's more convenient to give a step rather than a second item. What would people think about the notation [start .. end ; step] Also, [10..1] now returns [10], it should probably return the empty list. What about [10,11,.,0]? Also the empty list? I think so. Thoughts? As irange is based only on srange it will be fast now tick #701 is closed. Arguments enough to reopen ticket #706, I think. I don't think so, especially after resolving the issues above, but the two of us are probably equally bias about or own pieces of code. The only other person to have spoken up is William, maybe we should consider re-opening it if others speak up. I'm in favor of the [1..2] notation if the ambiguities can be resolved nicely. I agree that irange is sort of redundant if we have srange. But I haven't used any of these very much... Does your patch take care of this? sage: [1.2..3.5] [1.20, 2.20, 3.20, 4.20] -Jason --~--~-~--~~~---~--~~ 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: irange ticket #706 wontfix
On Sep 21, 2007, at 12:58 PM, Jaap Spies wrote: William Stein wrote: On 9/21/07, Robert Bradshaw [EMAIL PROTECTED] wrote: On Sep 21, 2007, at 5:40 AM, Jaap Spies wrote: I don't think so, especially after resolving the issues above, but the two of us are probably equally bias about or own pieces of code. The only other person to have spoken up is William, maybe we should consider re-opening it if others speak up. I am biased against irange because there is already: range, xrange, srange, and xsrange, and the argumetn for irange is to *lesson* confusion. Having irange will mean also having xirange, and that's just too many ranges for my brain. Why not prelude on Python 3k, where xrange will disappear? Python 3k is at least a year away, which is a lot time for SAGE. For now, we definitely need generators (for memory reasons) and lists. The Python long will also be obsolete, making things more simple. I'm actually not overly optimistic about this--I am wondering if it will just be more hidden from the user, but we will still have to distinguish between long-ints and int-ints in all of our Cython code for many things. (Either that or ints are taking a huge performance hit.) One example in the Tutorial will make a function like irange, or any other better name, acceptable for users: sage: sum(i for i in irange(1,10)) 55 I still think sage: sum([1..10]) 55 or sage: sum(1..10) 55 is easier to type and understand. I can just see trying to explain to half the students in a class (who got 45) see the little 'i' in there. - Robert --~--~-~--~~~---~--~~ 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: LLL
qflllgram is the gp function I use. It takes as input the gram matrix and outputs the unimodular transform. John On 9/21/07, Martin Albrecht [EMAIL PROTECTED] wrote: (first) try the FP variants of NTL's LLL first (I overlooked those before) These use real arithmetic internally, I think, but do not alow real input data as in my previous posting. Yes, it seems so. I am not very familiar with GP/Pari, which function implements what you want (gflllgram)? It is probably quite easy to wrap it for you once I know what to call. 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] -- 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-support] sage-2.8.5
On 9/21/07, Jaap Spies [EMAIL PROTECTED] wrote: William Stein wrote: Hi, SAGE 2.8.5 has been released at http://sagemath.org/. NOTE: Since this is such a major release, there will likely be problems and a 2.8.5.1 release shortly to fix them. Please report! Builds on Fedora 7, -- The following tests failed: sage -t devel/sage-main/sage/combinat/skew_tableau.py sage -t devel/sage-main/sage/combinat/ribbon.py Total time for all tests: 1838.3 seconds [EMAIL PROTECTED] sage-2.8.5]$ Many thanks for reporting this! This is from mike Hansen's new combinatorics code, I think. I *am* able to replicate this on my Fedora Core machine, and on none of my other 10 or so machines. Mike, any comments -- I can give you an account on the machine if necessary. This is now http://trac.sagemath.org/sage_trac/ticket/734 -- William See below. Jaap [EMAIL PROTECTED] sage-2.8.5]$ ./sage -t devel/sage-main/sage/combinat/skew_tableau.py sage -t devel/sage-main/sage/combinat/skew_tableau.py ** File skew_tableau.py, line 234: sage: SkewTableau([[None, 2], [1, 3]]).is_standard() Expected: True Got: False ** File skew_tableau.py, line 290: sage: SkewTableau([[None,1],[2],[3]]).restrict(2) Exception raised: Traceback (most recent call last): File /home/jaap/downloads/sage-2.8.5/local/lib/python2.5/doctest.py, line 1212, in __run compileflags, 1) in test.globs File doctest __main__.example_16[0], line 1, in module SkewTableau([[None,Integer(1)],[Integer(2)],[Integer(3)]]).restrict(Integer(2))###line 290: sage: SkewTableau([[None,1],[2],[3]]).restrict(2) File /home/jaap/downloads/sage-2.8.5/local/lib/python2.5/site-packages/sage/combinat/skew_tableau.py, line 297, in restrict raise ValueError, the skew tableau must be standard to perform the restriction ValueError: the skew tableau must be standard to perform the restriction ** File skew_tableau.py, line 292: sage: SkewTableau([[None,1],[2],[3]]).restrict(1) Exception raised: Traceback (most recent call last): File /home/jaap/downloads/sage-2.8.5/local/lib/python2.5/doctest.py, line 1212, in __run compileflags, 1) in test.globs File doctest __main__.example_16[1], line 1, in module SkewTableau([[None,Integer(1)],[Integer(2)],[Integer(3)]]).restrict(Integer(1))###line 292: sage: SkewTableau([[None,1],[2],[3]]).restrict(1) File /home/jaap/downloads/sage-2.8.5/local/lib/python2.5/site-packages/sage/combinat/skew_tableau.py, line 297, in restrict raise ValueError, the skew tableau must be standard to perform the restriction ValueError: the skew tableau must be standard to perform the restriction ** File skew_tableau.py, line 307: sage: SkewTableau([[None,1],[2],[3]]).to_chain() Exception raised: Traceback (most recent call last): File /home/jaap/downloads/sage-2.8.5/local/lib/python2.5/doctest.py, line 1212, in __run compileflags, 1) in test.globs File doctest __main__.example_17[0], line 1, in module SkewTableau([[None,Integer(1)],[Integer(2)],[Integer(3)]]).to_chain()###line 307: sage: SkewTableau([[None,1],[2],[3]]).to_chain() File /home/jaap/downloads/sage-2.8.5/local/lib/python2.5/site-packages/sage/combinat/skew_tableau.py, line 311, in to_chain raise ValueError, the skew tableau must be standard to convert to a chain ValueError: the skew tableau must be standard to convert to a chain ** 3 items had failures: 1 of 4 in __main__.example_14 2 of 2 in __main__.example_16 1 of 1 in __main__.example_17 ***Test Failed*** 4 failures. For whitespace errors, see the file .doctest_skew_tableau.py [1.5 s] exit code: 256 [EMAIL PROTECTED] sage-2.8.5]$ ./sage -t devel/sage-main/sage/combinat/ribbon.py sage -t devel/sage-main/sage/combinat/ribbon.py ** File ribbon.py, line 82: sage: Ribbon([[2,3],[1,4,5]]).is_standard() Expected: True Got: False ** 1 items had failures: 1 of 3 in __main__.example_5 ***Test Failed*** 1 failures. For whitespace errors, see the file .doctest_ribbon.py [1.5 s] exit code: 256 -- William Stein Associate Professor of Mathematics University of Washington
[sage-devel] Fwd: Trac rules
Regarding using trac / developing for SAGE: Are the guidelines available? Or should I reread the twisted document? At a minimum you should read the twisted page, though what we do is different... since we're not a company like them. It would be excellent if we were to write up a similar set of guidelines based on theirs. One thing: I saw in the contributors list, Me: a few random things... Maybe the other things I've done are more interesting: ... Maybe you could add; various other functions to the description? Sure. I should probably move that page to the wiki so people can update it themselves. What do people think about moving the contributors page to a wiki? Pro: It's easier to update and more complete Con: It doesn't hold as much weight to be listed, since just anybody can list themselves. Thoughts? Another thing is that I would like to have ... . Is Trac also the medium to place feature requests, or should we have something like the PEP's of Python? Read the twisted page ;-). If you're going to work on something, it's optimal if you create a trac enhancement ticket describing it, post to sage-devel mentioning it, and then start working on it, and sometimes post notes about progress to trac and even bundles. Or should I just start programming? Of course you can always do that :-) -- William Stein Associate Professor of Mathematics University of Washington http://wstein.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: [sage-support] sage-2.8.5
Many thanks for reporting this! This is from mike Hansen's new combinatorics code, I think. I *am* able to replicate this on my Fedora Core machine, and on none of my other 10 or so machines. Mike, any comments -- I can give you an account on the machine if necessary. This is now http://trac.sagemath.org/sage_trac/ticket/734 -- William Yeah, I can take a look at this. I'm not sure why it's coming up since that code isn't really doing anything interesting. I'll need an account on the machine though. --Mike --~--~-~--~~~---~--~~ 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: documentation changes
On 9/21/07, Jason Grout [EMAIL PROTECTED] wrote:
William Stein wrote:
Incidentally, the whole sage documentation structure started from
the Python documentation (probably Python 2.4), which I just
motivated to be the Sage manuals instead. I had experimented
a lot with automated tools like epydoc, etc., and found that they
break a lot on the incredibly complicated Sage library, they don't
play well with Cython code (which is nearly 1/3rd of Sage?), and
and they just don't feel as well organized and readable as something
that a person has to spend time putting together. The current
documentation -- though not comprehensive -- tends to only
have things in it that are reasonably usable and stable, so the
stuff that epydoc would pick up that is really a mess isn't there.
That said, *pydoc has probably improved a lot in the last 2 years
(since I last used it), and it would be good to have some 100%
complete autogenerated variant of the reference manual in
addition to the current more manually organized one.
Is one requirement for any such system the ability to deal with math in
the documentation?
That would be nice and is a big advantage of the current latex system.
That said, something autogenerated with ugly math in it (not typeset)
would be useful, probably.
After browsing for a little bit, it seems like that
is a sticky point that many systems don't address, other than pydoc,
though epydoc does have some sort of construct for math ( X{x+y} ).
It's nice now to have the documentation in latex so that we can write a
mathematical explanation.
No matter what, the input in doctests will be latex notation. I'm definitely
not going to consider using some funky math notation for the documentation.
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: Fwd: Trac rules
William Stein wrote: One thing: I saw in the contributors list, Me: a few random things... [...] Sure. I should probably move that page to the wiki so people can update it themselves. What do people think about moving the contributors page to a wiki? Pro: It's easier to update and more complete Con: It doesn't hold as much weight to be listed, since just anybody can list themselves. Thoughts? -1 I think people can speak, if they feel something is wrong. Jaap --~--~-~--~~~---~--~~ 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: documentation changes
William Stein wrote:
Incidentally, the whole sage documentation structure started from
the Python documentation (probably Python 2.4), which I just
motivated to be the Sage manuals instead. I had experimented
a lot with automated tools like epydoc, etc., and found that they
break a lot on the incredibly complicated Sage library, they don't
play well with Cython code (which is nearly 1/3rd of Sage?), and
and they just don't feel as well organized and readable as something
that a person has to spend time putting together. The current
documentation -- though not comprehensive -- tends to only
have things in it that are reasonably usable and stable, so the
stuff that epydoc would pick up that is really a mess isn't there.
That said, *pydoc has probably improved a lot in the last 2 years
(since I last used it), and it would be good to have some 100%
complete autogenerated variant of the reference manual in
addition to the current more manually organized one.
Is one requirement for any such system the ability to deal with math in
the documentation? After browsing for a little bit, it seems like that
is a sticky point that many systems don't address, other than pydoc,
though epydoc does have some sort of construct for math ( X{x+y} ).
It's nice now to have the documentation in latex so that we can write a
mathematical explanation.
-Jason
--~--~-~--~~~---~--~~
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
On 9/21/07, Hamptonio [EMAIL PROTECTED] wrote: Were any of these ideas ever implemented? I am occaisonally messed up by the worksheet quietly restarting without my realizing it. (In that No work has been done on this. I've made this http://trac.sagemath.org/sage_trac/ticket/735 so it doesn't get lost in the shuffle. I've recently become a heavy user of screen (the unix tool), and now my perspective how been somewhat changed... I definitely want to rework how timing out works -- i.e., it never happens by default, when you visit your homepage in the notebook it clearly shows all worksheets with a running sage session, etc. Design discussion would be welcome here. Please try out screen if you haven't already too. regard I believe there is a minor bug: when the notebook restarts, it does not add the red bars on the left to indicate an un-executed cell.) I used to use the auto_restart option on a long enough setting that I could intermittingly work on it all day without a restart (8 seconds or so). Will that option be added back in at some point? On Aug 23, 12:16 am, William Stein [EMAIL PROTECTED] wrote: On 8/22/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: (By the way, I think it's a known bug that if I hit the save button, then things I've entered into a cell don't get saved if I didn't hit shift-enter.) That is not a bug - it is by design. We may consider changing this behavior though. I think this is a poor idea, interface-wise. What do you think is a poor idea? Changing the behavior or not changing the behavior? When I hit save, I want it to look the same when I come back. In fact, I'm having trouble figuring out what the save button does, if this is the case. When you press shift-enter, it saves the cell... when you press save... ? In addition, when you press save it forces a snapshot to be saved to disk, which you can revert to later. If the server dies, the worksheet is thus saved. -- William -- William Stein Associate Professor of Mathematics University of Washington http://wstein.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: LLL
(first) try the FP variants of NTL's LLL first (I overlooked those before) (then) try Damien's fast.c implementation, also the proved version seems interesting, given the discussions on this list. So, after I understood a bit better what makes LLL algorithms fast, here is what I came up with so far. I wrapped the approximate LLL versions of NTL. Joel, thank you 1000 times for making it possible to strip one layer for the NTL interface because I wrote 18 Pyrex interfaces (for 9 overloaded C++ functions) for NTL's LLL alone. And I didn't cover everything! From what I read MAGMA also uses approximate variants (overall they have 8 LLL implementations according to the manual), but they can do so because they can prove that the result is LLL reduced. That should translate to Damien's provable GPL implementation. However, I am not entirely sure what the result from the floating point variants in NTL is. Shoup writes: Routines are provided for lattice basis reduction, including both exact-aritmetic variants (slow but sure) and floating-point variants (fast but only approximate). What I do not understand is, if a not LLL reduced basis can be returned by the FP variants without that an exception is raised. I would appreciate input from somebody more experienced here. As an example consider the example from the MAGMA documentation: sage: B = MatrixSpace(IntegerRing(), 50, 51)(0 sage: for i in range(50): B[i,0] = ZZ.random_element(2**1) sage: for i in range(50): B[i,i+1] = 1; Trying the fastest one: sage: B.LLL(algorithm=NTL:LLL_FP) LLL_FP: numbers too big...use LLL_XD ... type 'exceptions.RuntimeError' We try what NTL suggested: sage: time B.LLL(algorithm=NTL:LLL_XD) 50 x 51 dense matrix over Integer Ring CPU time: 43.55 s, Wall time: 44.73 s So, can we be sure now that this is correct? MAGMA's time: sage: M = magma(B) sage: time C = M.LLL() Wall: 15.53 s Also, MAGMA seems to use an heuristic to choose which LLL implementation out of eight is the best (and they say it is not very good) so I wonder if we should also make a choice if algorithm==None (defaults to exact version for now). So NTL is still behind but not as bad as before. I assume qflllgram() for John is next on the LLL List and then I'l have to look into Damien's GPL code. Martin PS: #723 updated. -- 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: irange ticket #706 wontfix
On Sep 21, 2007, at 12:55 PM, Jason Grout wrote: Robert Bradshaw wrote: Also, [10..1] now returns [10], it should probably return the empty list. What about [10,11,.,0]? Also the empty list? I think so. Thoughts? Well, it ought to go to infinity, wrap to negative infinity, and then back up to zero, of course :). Just treat it like the one-point compactification of the real line, going the long way around. :-) Should the following be valid? [10,20..15] for the list [10,20,19,18,17,16,15]. Currently, it would be [] as [10,20..100] would expand to [10,20,30,40,50,60,70,80,90,100] Perhaps there should be a distinction between [10,11,..,0] and [10,11..0]. [10,11,..,0] is an error, while [10,11..0] is okay (i.e., without the commas, the step is assumed to be 1 or -1). Hmm... the with vs. without commas is hard to see. Making [10,11,..,n] an error depending on the value of n is unsettling too. I've put another patch up on trac that handles empty ranges gracefully. Once can also write [0..10, step=2] now. - Robert --~--~-~--~~~---~--~~ 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: Fwd: Trac rules
What about an intermediate solution: once someone is a contributor, you could give them edit access to a wiki page listing contributors, and then they could keep their entry current. On Sep 21, 5:53 pm, [EMAIL PROTECTED] wrote: Sure. I should probably move that page to the wiki so people can update it themselves. What do people think about moving the contributors page to a wiki? Pro: It's easier to update and more complete Con: It doesn't hold as much weight to be listed, since just anybody can list themselves. +1 I don't think the con is valid, these days. If somebody adds something fishy, contact them / remove it / block their wiki account, depending on severity. --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
