[sage-devel] memory leak or some other weirdness
Consider the following script, which saves a p-adic matrix and then repeatedly loads it into a list: == from time import time K = Qp(13, 10) M = Matrix(K, [[K.random_element() for j in range(200)] for k in range(200)]) M.save(thing.sobj) L = [] for i in range(40): last = time() L.append(load(thing.sobj)) now = time() print took %.2f seconds % (now - last) last = now == Here is typical output for sage 4.5.3, AMD linux: == took 0.21 seconds took 0.21 seconds took 0.39 seconds took 0.21 seconds took 0.44 seconds took 0.21 seconds took 0.48 seconds took 0.21 seconds took 0.21 seconds took 0.51 seconds took 0.21 seconds took 0.56 seconds took 0.21 seconds took 0.60 seconds took 0.21 seconds took 0.21 seconds took 0.64 seconds took 0.20 seconds took 0.69 seconds took 0.20 seconds took 0.73 seconds took 0.20 seconds took 0.21 seconds took 0.77 seconds took 0.21 seconds took 0.81 seconds took 0.20 seconds took 0.86 seconds took 0.21 seconds took 0.21 seconds took 0.89 seconds took 0.20 seconds took 0.94 seconds took 0.20 seconds took 0.98 seconds took 0.20 seconds took 0.21 seconds took 1.02 seconds took 0.20 seconds took 1.07 seconds == About half of them are 0.2 seconds, but the rest keep getting longer and longer, apparently the increase is linear in the number of iterations. This smells like some kind of weird leak, but I'm not sure. Any thoughts? 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] Sage is embarrassingly slow
Dear sage-devel, Sage is very slow. I discovered this (again) while trying to write a prototype of an algorithm for computing zeta functions of projective varieties. I need to multiply lots of polynomials and matrices over finite rings, and frequently move coefficients between polynomials and matrices. The arithmetic is actually not too bad; it's the boring data movement stuff that really sucks. I made a bunch of tickets: http://trac.sagemath.org/sage_trac/ticket/9882 http://trac.sagemath.org/sage_trac/ticket/9883 http://trac.sagemath.org/sage_trac/ticket/9884 http://trac.sagemath.org/sage_trac/ticket/9885 http://trac.sagemath.org/sage_trac/ticket/9886 http://trac.sagemath.org/sage_trac/ticket/9887 http://trac.sagemath.org/sage_trac/ticket/9888 Maybe I can be the first to #1 if I keep going! 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] overhead in creating p-adic elements
Hi, sage: K = Qp(13, 5) sage: 13^5 371293 sage: y = K(10) sage: z = K(20) sage: timeit(x = y * z) 625 loops, best of 3: 961 ns per loop # varies a bit but this is typical sage: timeit(x = y + z) 625 loops, best of 3: 942 ns per loop # ditto That's the cost of arithmetic. Pretty slow in my opinion, but anyway. Here is the real problem: sage: timeit(x = K(4)) 625 loops, best of 3: 22.6 µs per loop sage: y = int(4) sage: timeit(x = K(y)) 625 loops, best of 3: 23.2 µs per loop sage: from sage.rings.padics.padic_capped_relative_element import pAdicCappedRelativeElement sage: timeit(x = pAdicCappedRelativeElement(K, 4)) 625 loops, best of 3: 17.6 µs per loop So there seems to be serious overhead in several places. Note that the cost cannot be in determining the valuation, since the simple x = y + z would have to do that too. I ran into this while trying to multiply a p-adic by an integer: sage: y = K(10) sage: z = 20 sage: timeit(x = y * z) 625 loops, best of 3: 23.9 µs per loop Is there an easy way to fix this? 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] silly license question
I am confused. I want to release bernmm 1.1 under the (modified) BSD license. It depends on NTL, which is GPL-licensed. Can I do this? Or am I forced to release bernmm under GPL? 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: round(), floor() and ceil() on interval objects
I disagree with this change. One of the main purposes of interval arithmetic is to be able to take a function f(x) that operates on floats, and pass in intervals instead, to determine the possible range of outputs a given input interval could produce. This change violates that paradigm. The author of f(x) shouldn't need to care whether they are operating on floats or intervals. david On Sep 17, 3:53 am, Jason Grout jason-s...@creativetrax.com wrote: Currently, round(), floor(), and ceil() on interval objects return intervals. There is a patch up at #2899 that changes these functions to return integers (round- round the midpoint, floor - largest integer below the bottom of the interval, etc.). I think the reasoning is that round(), floor, ceil, etc. should always return integers. What do people think? Should we close the ticket, or should we merge the patch (after possible rebasing). To illustrate: Currently: sage: R = RealIntervalField(100) sage: a = R(9.5, 11.3); a.str(style='brackets') '[9.500 .. 11.300710542735760101]' sage: floor(a).str(style='brackets') '[9.000 .. 11.00]' Proposed: sage: floor(a) 9 Thanks, Jason -- Jason Grout --~--~-~--~~~---~--~~ 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.0.2.rc0 released
On Jun 15, 9:57 am, William Stein wst...@gmail.com wrote: File /Users/was/build/sage-4.0.2.rc0/devel/sage/doc/en/bordeaux_2008/birds_other.rst, line 212: sage: w = bernoulli(10, num_threads=16) # 1.87 seconds Exception raised: Traceback (most recent call last): [...] This is now http://sagetrac.org/sage_trac/ticket/6304. 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: coercion issue?
This is now http://sagetrac.org/sage_trac/ticket/6168. david On May 30, 12:03 pm, Bill Hart goodwillh...@googlemail.com wrote: Regarding compilation with debug, zn_poly is passed the flag -DNEBUG for a couple of files, instead of -DNDEBUG. This is a sloppy typo on my part. Originally I think I took the output from the zn_poly configure script, but in the latest version there were some new files, and I guess I added the targets by hand to the FLINT makefile. At any rate, that is not the cause of our problems, and I will fix it in the next version of FLINT. As for something not being reduced before being passed to zn_poly, it is likely that someone assumed FLINT reduces coefficients mod p before doing anything with them, which it does not. I met at least one such person. It would be a performance issue to do this at any level. Instead, FLINT assumes all polynomials it is passed have reduced coefficients and it guarantees too return polynomials which respect this, except for I think one function (zmod_poly_add_nored I think) which would be specifically documented as not doing so. Sorry none of this actually helps find the bug. It is still possible of course that zn_poly is actually being passed garbage by FLINT, and that garbage just happens to not be reduced. At some point in Martin's wrapper of zmod_poly in Sage, there was an option you could switch on to compare the output from FLINT with that of Pari. Thus helped us track down the specific polynomial computation which caused the issue last time. Bill. On 30 May, 06:11, David Harvey dmhar...@cims.nyu.edu wrote: On May 29, 10:54 pm, David Harvey dmhar...@cims.nyu.edu wrote: Hmmm let me try again. Would appreciate help from people familiar with FLINT wrapper and/or coercion system. sage: R.x = PolynomialRing(Integers(121)) sage: S.y = PolynomialRing(Integers(11)) sage: S(50*x) 6*y sage: R(S(50*x)) 50*x # !! I think what's actually happening is that the underlying FLINT zmod_poly object is not getting coefficients reduced into [0, 10]. This causes other problems indirectly (e.g. #5817). I can't quite trace why this is happening. Any ideas? There is a also a performance issue. The following is in sage 3.4.2: sage: R.x = PolynomialRing(Integers(11^6)) sage: S.y = PolynomialRing(Integers(11^3)) sage: f = R([ZZ.random_element(11^6) for _ in range(100)]) sage: time g = f * f CPU times: user 0.96 s, sys: 0.01 s, total: 0.97 s Wall time: 0.96 s sage: f = S(f) sage: time g = f * f CPU times: user 0.93 s, sys: 0.00 s, total: 0.93 s Wall time: 0.93 s sage: f = S([ZZ.random_element(11^3) for _ in range(100)]) sage: time g = f * f CPU times: user 0.55 s, sys: 0.00 s, total: 0.55 s Wall time: 0.55 s What appears to be happening is that FLINT is using kronecker substitution for the multiplication (packing polynomials into an integer and then multiplying the integers), but in the second multiplication above it is *not* reducing mod 11^3 before doing this. Even better evidence is the following: if I install flint 1.2.5 (as per trac #5817) I get: sage: R.x = PolynomialRing(Integers(11^6)) sage: S.y = PolynomialRing(Integers(11^3)) sage: f = R([ZZ.random_element(11^6) for _ in range(100)]) sage: f = S(f) sage: time g = f * f sage.bin: zn_poly/src/zn_poly.h:185: zn_mod_add_slim: Assertion `x mod-m y mod-m' failed. /home/dmharvey/5817/sage-3.4.2-new/local/bin/sage-sage: line 198: 16421 Aborted (core dumped) sage-ipython $@ -i This means two things: (1) zn_poly is getting compiled with debug assertions, which it shouldn't, since this is a major performance loss, and (2) some zn_poly routine is getting called on a polynomial with non-normalised coefficients. But I still don't know exactly where the non-normalisation is happening. 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: coercion issue?
I'm an idiot, it's a not a bug. I misunderstood the definition of change_ring. Sorry for the noise. david On May 29, 7:46 pm, dmharvey dmhar...@cims.nyu.edu wrote: Is this a bug? sage: version() 'Sage Version 3.4.2, Release Date: 2009-05-05' sage: S.t = PolynomialRing(Integers(14641)) sage: f = 1 + 9581*t sage: R = PolynomialRing(Integers(1331), t) sage: ff = f.change_ring(R) sage: ff 264*t + 1 sage: type(f) type 'sage.rings.polynomial.polynomial_zmod_flint.Polynomial_zmod_flint' sage: type(ff) type 'sage.rings.polynomial.polynomial_element.Polynomial_generic_dense' sage: ff[0] 264*t + 1 sage: f[0] 1 sage: type(ff[0]) type 'sage.rings.polynomial.polynomial_zmod_flint.Polynomial_zmod_flint' (This came up in relation to trac #5817) --~--~-~--~~~---~--~~ 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: coercion issue?
Hmmm let me try again. Would appreciate help from people familiar with FLINT wrapper and/or coercion system. sage: R.x = PolynomialRing(Integers(121)) sage: S.y = PolynomialRing(Integers(11)) sage: S(50*x) 6*y sage: R(S(50*x)) 50*x # !! I think what's actually happening is that the underlying FLINT zmod_poly object is not getting coefficients reduced into [0, 10]. This causes other problems indirectly (e.g. #5817). I can't quite trace why this is happening. Any ideas? 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: coercion issue?
On May 29, 10:54 pm, David Harvey dmhar...@cims.nyu.edu wrote: Hmmm let me try again. Would appreciate help from people familiar with FLINT wrapper and/or coercion system. sage: R.x = PolynomialRing(Integers(121)) sage: S.y = PolynomialRing(Integers(11)) sage: S(50*x) 6*y sage: R(S(50*x)) 50*x # !! I think what's actually happening is that the underlying FLINT zmod_poly object is not getting coefficients reduced into [0, 10]. This causes other problems indirectly (e.g. #5817). I can't quite trace why this is happening. Any ideas? There is a also a performance issue. The following is in sage 3.4.2: sage: R.x = PolynomialRing(Integers(11^6)) sage: S.y = PolynomialRing(Integers(11^3)) sage: f = R([ZZ.random_element(11^6) for _ in range(100)]) sage: time g = f * f CPU times: user 0.96 s, sys: 0.01 s, total: 0.97 s Wall time: 0.96 s sage: f = S(f) sage: time g = f * f CPU times: user 0.93 s, sys: 0.00 s, total: 0.93 s Wall time: 0.93 s sage: f = S([ZZ.random_element(11^3) for _ in range(100)]) sage: time g = f * f CPU times: user 0.55 s, sys: 0.00 s, total: 0.55 s Wall time: 0.55 s What appears to be happening is that FLINT is using kronecker substitution for the multiplication (packing polynomials into an integer and then multiplying the integers), but in the second multiplication above it is *not* reducing mod 11^3 before doing this. Even better evidence is the following: if I install flint 1.2.5 (as per trac #5817) I get: sage: R.x = PolynomialRing(Integers(11^6)) sage: S.y = PolynomialRing(Integers(11^3)) sage: f = R([ZZ.random_element(11^6) for _ in range(100)]) sage: f = S(f) sage: time g = f * f sage.bin: zn_poly/src/zn_poly.h:185: zn_mod_add_slim: Assertion `x mod-m y mod-m' failed. /home/dmharvey/5817/sage-3.4.2-new/local/bin/sage-sage: line 198: 16421 Aborted (core dumped) sage-ipython $@ -i This means two things: (1) zn_poly is getting compiled with debug assertions, which it shouldn't, since this is a major performance loss, and (2) some zn_poly routine is getting called on a polynomial with non-normalised coefficients. But I still don't know exactly where the non-normalisation is happening. 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 Installation error (due to gmp-mpir-0.9's installation ) on Playstation 3 (with Ubuntu 8.10 Linux)
On May 19, 11:17 pm, David Harvey dmhar...@cims.nyu.edu wrote: On May 19, 1:58 pm, Ralf-Philipp Weinmann crypto@gmail.com wrote: zn_poly/pack.c:86:2: error: #error Not nails-safe yet zn_poly/pack.c:168:2: error: #error Not nails-safe yet zn_poly/pack.c:252:2: error: #error Not nails-safe yet zn_poly/pack.c:351:2: error: #error Not nails-safe yet zn_poly/pack.c:433:2: error: #error Not nails-safe yet Is there any easy fix to this? Apparently it's compiling in 32-bit mode. If you want full logs, I can put them up. This message indicates that zn_poly thinks either that GMP is compiled with nails support (which I doubt), or that unsigned long is a different width from mp_limb_t. I can think of several possible causes (1) Sage is actually compiling with unsigned long != mp_limb_t, or (2) GMP/MPIR is not defining things like GMP_NUMB_BITS correctly, etc. In case (1), there is no easy fix (the next version of zn_poly will be able to handle mp_limb_t != unsigned long, but won't be ready for release for a few months yet). In case (2), hopefully the MPIR guys can help debug. Sorry, in case (1), I should have said, there is no easy fix from within zn_poly itself. If Sage is not supposed to be compiling with unsigned long != mp_limb_t, then if you can figure out how to make it use unsigned long == mp_limb_t, everything should work fine. 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 Installation error (due to gmp-mpir-0.9's installation ) on Playstation 3 (with Ubuntu 8.10 Linux)
On May 19, 11:41 pm, mabshoff mabsh...@googlemail.com wrote: Well, in this case it is completely ironic that the zn_poly 0.9 code in FLINT is compiled, but not used since it causes a doctest failure in the Monsky code. When using only FLINT it passes the doctest. The failure is a different one compared to when FLINT shipped with zn_poly 0.8, but there are two possibilities: (a) the glue code from FLINT to zn_poly or some other change Bill might have made to zn_poly inside FLINT causes the bug (b) zn_poly 0.9 has an undetected bug. Ok, I wasn't aware of this, let me know when/if you have more details. 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: Clarification of Sage and GPL
On May 6, 10:41 am, kcrisman kcris...@gmail.com wrote:
So is there any final consensus on this? Is the following Sage
program automatically GPL?
{{{
2+2
}}}
Or only in the following form?
{{{
Integer(2)+Integer(2)
}}}
Please no flames! I only wanted to know if there was a consensus, I
got sort of confused by 50 messages on this in my RSS reader at once.
If there isn't a consensus (and it seems there is not) then please
don't reply, and I will go along with Rob B. and publish whatever Sage
worksheets I want to under whatever license I deem appropriate, if
any.
Totally awesome thread guys.
What about this one?
def is_prime(n):
return not any([1 * n / d == n // d for d in range(2, n)])
Works in sage, but not in python. Is it GPL?
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 release plan
On Apr 24, 2:26 pm, Tim Abbott tabb...@mit.edu wrote: As I understand it, David Harvey isn't physically at NYU yet and nobody had mentioned the patch to Victor prior to my sending it to Victor. Actually, I've been physically at NYU since last July, i.e. almost a year. But Victor has been away on sabbatical, I haven't even met him face-to-face yet. 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: GMP 4.3.0
Oh look, I've been involved in Sage since mid-2006. This is the first major strategic decision with which I've disagreed so strongly, and the first time I've felt truly unwelcome on this list. It's quite depressing. I sincerely believe the costs of the fork to the community outweigh the benefits. Probably no-one will believe me, but this whole kerfuffle started as a result of me trying some shuttle diplomacy to get the two projects talking. The personal animosities involved are quite astonishing. Hopefully my planned career as a mathematician will be more successful than my career as a diplomat. Anyway, forget it. Good luck with MPIR guys. 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: GMP 4.3.0
On Apr 21, 3:08 pm, Robert Bradshaw rober...@math.washington.edu wrote: I wish all forks could be as amicable as the Pyrex/Cython one, but understandably that is rarely the case. I support the reasons behind MPIR, but I think it's a very good thing to provide a GMP spkg for Sage--it gives users the choice. But Robert, that choice is illusory. Already it's impossible to install the gmp-4.3 spkg without breaking all those doctests. Over time, it's inevitable that the APIs of the two packages will diverge, unless the projects can come to some kind of agreement. I can't see how this can be a good thing. 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: GMP 4.3.0
On Apr 21, 2:31 pm, Bill Hart goodwillh...@googlemail.com wrote: In some cases it would be less work to just contribute features directly to MPIR to bring the current code up to par. I think you are underestimating how much work it is to design, write and debug these things. And whatever happened to not reinventing the wheel? I suppose that's a Sage motto but not an MPIR one? 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: GMP 4.3.0
On Apr 21, 8:06 pm, Robert Bradshaw rober...@math.washington.edu wrote: The only doctests that break are the xgcd ones, right? This has been an issue before, and so I think perhaps the doctests should be improved. Also some doctests related to modular symbols. I don't know enough about this area to tell whether it's xgcd related or whether it's really a new bug in GMP. Over time, it's inevitable that the APIs of the two packages will diverge, unless the projects can come to some kind of agreement. I can't see how this can be a good thing. You're right, I don't see this as a good long-term solution. I really hope the two projects can come to some kind of agreement--the current situation is in many ways a waste of time and recourses. Of course this may be wishful thinking given the clashing of goals, licensing issues, and personalities. However, the (upper level) gmp api is pretty stable as far as api's go, so I think it's good to have this option in the short term while the dust settles until a better relationship between the projects can be reached. I am talking about the mpn-level interface, which is relevant for a lot of the things I work on. 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: p-adic precision loss in charpoly
Hi guys, Thanks for looking into this. I ended up working around the problem by lifting to Z and doing the charpoly there (I know in advance the output precision, and the complexity is not that important for my application, so it's no big deal). I've put up a patch for review here: http://sagetrac.org/sage_trac/ticket/793 (wink wink nudge nudge) david On Mar 19, 10:00 am, David Kohel drko...@gmail.com wrote: Hi, The algorithm used doesn't need to be specific to the p-adics, but shouldn't apply an algorithm for fields or integral domains. Rather than the matrix code, it looks like this is the source of the problem: sage: M.parent().base_ring() 101-adic Ring with capped relative precision 2 sage: R.is_integral_domain() True With such a result, the wrong linear algebra is applied. One could possibly identify which algorithms to apply for real complex fields, p-adics, and power series rings from this: sage: R.is_exact() False Inexact rings are only approximations to mathematical objects. However, in this case the intended ring is the quotient ring Z/p^nZ (= Z_p/p^n Z_p), which is 'exact' (i.e. a well-defined ring) but is not an integral domain. I would hope that the matrix code would then pick up a valid algorithm to apply, even if not the most efficient. --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: hyperelliptic curve constructor question
Awesome! Looks like your patch is a little more comprehensive than what I was planning, I might pick and choose a bit :-) david On Mar 15, 11:09 pm, Nick Alexander ncalexan...@gmail.com wrote: My wrapper that I never got around to submitting... Nick frobenius.py 10KViewDownload On 15-Mar-09, at 7:59 PM, Alex Ghitza wrote: Hi David, On Mon, Mar 16, 2009 at 1:12 PM, David Harvey dmhar...@cims.nyu.edu wrote: Ah. The reason I asked is that various people have requested that I write a better wrapper for my hypellfrob library in Sage, and I was about to try doing that. I thought it should be some kind of method frobenius_charpoly or something attached to a hyperelliptic curve object, and I was trying to find out what already existed. The count_points and zeta_series interfaces don't seem quite right for this. But if you guys are working heavily on that code now, perhaps you can tell me where the code should go, and I can put up a patch, which you might need to merge if things change too much in the meantime. I'm very happy you're wrapping hypellfrob in Sage. I agree with Justin's suggestion that you should just attach it to the existing hyperelliptic code in whatever way is most convenient to you. If in the course of refactoring that code we need to make some changes to what you did, we'll deal with that there and then. And please open tickets if you run into stupid stuff along the way. We'll try to get issues fixes as we go along. Best, Alex 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: hyperelliptic curve constructor question
On Mar 15, 10:00 pm, Justin Walker jus...@mac.com wrote: The short answer is: we're working on it (as a part of an SD14 project). The whole schemes directory is being scrubbed (and of course, it takes time to figure out what is intended, before cleaning it up). Trac items will appear in due course, but if you find something, feel free to create a Trac report for it. Add any information you feel is useful (including patches :-}). There isn't much of a long answer right now -} Justin Ah. The reason I asked is that various people have requested that I write a better wrapper for my hypellfrob library in Sage, and I was about to try doing that. I thought it should be some kind of method frobenius_charpoly or something attached to a hyperelliptic curve object, and I was trying to find out what already existed. The count_points and zeta_series interfaces don't seem quite right for this. But if you guys are working heavily on that code now, perhaps you can tell me where the code should go, and I can put up a patch, which you might need to merge if things change too much in the meantime. (This is also related to my unanswered question on sage-devel a few days ago about characteristic polynomials of p-adic matrices, but I know how to work around that bug.) 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.3 fails to build (preserving permissions problem)
Hi, I had the same problem a month or two ago with sage 3.1.2 (?) but didn't report it. I had the same problem just now with sage 3.3. I tried fixing the NTL build by removing the -p options but then the build failed for whatever came next (eclib I believe). Then I found this thread and realised it was probably a filesystem issue. I tried doing the sage build on my local drive (/scratch) instead of the NFS drive and now it seems to be working smoothly. 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: Fwd: [MPFR] new license for GNU MPFR
On Mar 5, 10:28 pm, Bill Hart goodwillh...@googlemail.com wrote: Let's clear up another misconception here. GPL v3+ software is NOT banned from Sage. This is explicitly stated online. Where does it say this? The comments on this thread suggest that Sage will not upgrade to the next release of MPFR solely because of the license change, which suggests that a de facto ban on GPL3 code is in place. It just doesn't get included in the GPL v2+ version of Sage, What do you mean, GPL v2+ version of Sage? Where can I download this version? As far as I know, there is only one Sage download available, and it does not include any GPL3 code. 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: Fwd: [MPFR] new license for GNU MPFR
On Mar 6, 7:27 am, Robert Bradshaw rober...@math.washington.edu wrote: I would guess that sooner or later we will accept GPL3 packages into Sage, while still maintaining the GPL2-only version for a while (which will become more and more obsolete as GPL3 upstream packages evolve). Time will tell. I hope this is true. My worry is that Sage does not have the developer resources or willpower to maintain two separate versions. I think it will get harder and harder, especially with all the forking activity going on. 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: Fwd: [MPFR] new license for GNU MPFR
On Mar 6, 9:49 am, William Stein wst...@gmail.com wrote: As far as I know, there is only one Sage download available, and it does not include any GPL3 code. It does. Ah. So am I correct in deducing that MSR employees are unable to use Sage 3.3? 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: Fwd: [MPFR] new license for GNU MPFR
Hmmm okay, it looks like I have been guilty of contributing to some of the misinformation on this thread. My apologies for this. 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: Fwd: [MPFR] new license for GNU MPFR
On Mar 5, 1:10 am, Robert Bradshaw rober...@math.washington.edu wrote: Can you 'backport' code from a GPL3L+ code base to a [L]GPLv2+ code base? Just curious. Not code, but you can read the release notes and then fix the bugs yourself. Surely this becomes a stupid waste of time at some point. Not reinventing the wheel, etc etc. 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: Bordeaux talk tomorrow
There is a typo on the page Matrix of Frobenius on Hyperelliptic
Curves. Where you say We do the same calculation over the bigger
field F_{101^4}, it's not doing anything over an extension field.
It's computing in Z/101^4 Z.
david
On Oct 15, 2008, at 6:52 PM, William Stein wrote:
Hi,
I'm giving a talk at Bordeaux tomorrow that is a sort of birds eye
view overview
of number theory functionality in Sage. I've attached my slides to
this email.
-- William
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
bordeaux.pdf
--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] macports
This is the first time I've seen this: Found MacPorts in /opt/local/bin/port * Found either MacPorts or Fink in your path, which potentially wrecks the Sage build process. You should make sure MacPorts and Fink cannot be found. Either: (1) rename /opt/local and /sw, or (2) change PATH and DYLD_LIBRARY_PATH (Once Sage is built, you can restore them.) * Would it be excessively uncivilised to *automatically* change the path during the build process? 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: macports
On Oct 5, 2008, at 5:32 AM, Justin C. Walker wrote: On Oct 5, 2008, at 02:11 , David Philp wrote: Would it be excessively uncivilised to *automatically* change the path during the build process? Well, the kind of people who will come across it will be capable of changing their own path---and maybe sensitive. And, it might require root permissions. Changing the PATH and related environment variables does not require any permissions. However, these variables can be modified each time a shell starts up, depending on how the startup works, so that may not suffice. It's kind of tricky, but David's suggestion makes sense to me. I've worked around this by changing the settings in my startup file, and that may be uncivilized. If it can be done without modifying the local startup files, that would be ideal. Any other thoughts? Two other thoughts. (1) this is the first time ever that I can recall sage not building on my machine by simply issuing make. I think it's a Bad Thing that this now happens. It will happen to me every time I build sage because I do not want to remove MacPorts permanently. (2) Here's how I got around it. I looked at my environment by typing env. Then I manually typed in export PATH=, including all the directories in my original PATH minus the ones involving /opt/local. Then I ran make. This seems to work. But Justin suggests above that this might not be enough; perhaps other shells being created during the build process are using a path from some startup script, which I haven't changed. So even though I am the kind of person who is capable of changing my path, but I actually have no idea what I'm doing, and quite possibly tricked sage into doing the wrong thing anyway. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: C/C++ Library Versioning in Sage
Hi guys, The present discussion was precipitated by my submission of the zn_poly 0.9 spkg, which included some modifications to the makefile suggested by Tim, specifically the library versioning stuff. I still don't totally understand what's going on, but the ensuing discussion has been very illuminating (thanks everyone!) I think from my point of view the crux of the matter is this exchange: On Sep 28, 2008, at 1:25 PM, mabshoff wrote: On Sep 27, 8:50 am, Tim Abbott [EMAIL PROTECTED] wrote: But no binary Linux distribution can distribute the Sage dependencies unless they do proper library versioning. Sure, but that is not the problem I need to solve :) So, in other words, it's useful for the purposes of Debian packaging for me to do proper library versioning, at least as far as indicating when interfaces change. On the other hand, Michael doesn't think versioning is important for Sage, and he points out that the method suggested by Tim is GNU-specific, whereas I don't want zn_poly to be GNU-specific (as far as I can help it). But at the end of the day, as long as I provide the versioning information, both Sage and Debian can trivially patch the makefile to make it work how they want. I think I know enough about the Sage build system to be able to handle this myself for the spkg (with occasional guidance from mabshoff). So my question becomes: how do I provide versioning information in a non-GNU-specific way? I guess if I can do this then I can make everyone happy. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: does PARI know the primes up to 35?
On Sep 23, 2008, at 7:26 PM, Craig Citro wrote: sage: K.a = CyclotomicField(23) sage: K.class_number() ... PariError: not enough precomputed primes, need primelimit ~ (35) Hah, that's pretty hilarious. :) Actually, what it's telling you is that it needs primes up to a primelimit, and then it doesn't actually put in the primelimit. (This is a bug in our processing of Pari's error messages.) It's then saying that this is PariError #35. The effect is awesome, though. [...] And maybe one last good question: David, were you surprised that Pari/Sage couldn't tell you this? Would you have preferred a non-verified answer (along with information that it wasn't provably correct, of course), what you got, or something else entirely? I just wanted to know the class number of that field! (More precisely, I was trying to remember which was the first cyclotomic field with non-trivial class group.) It would have been okay to get a non-verified answer with the information that it was non-verified but then I would have wanted to be able to try again to get the verified answer. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] does PARI know the primes up to 35?
--
| SAGE Version 3.1.2, Release Date: 2008-09-19 |
| Type notebook() for the GUI, and license() for information.|
--
sage: K.a = CyclotomicField(23)
sage: K.class_number()
*** Warning: large Minkowski bound: certification will be VERY
long.
---
PariError Traceback (most recent call
last)
/home/dmharvey/ipython console in module()
/home/was/s/local/lib/python2.5/site-packages/sage/rings/number_field/
number_field.py in class_number(self, proof)
2068
2069 proof = proof_flag(proof)
- 2070 return self.class_group(proof).order()
2071
2072 def composite_fields(self, other, names=None):
/home/was/s/local/lib/python2.5/site-packages/sage/rings/number_field/
number_field.py in class_group(self, proof, names)
2038 except AttributeError:
2039 self.__class_group = {}
- 2040 k = self.pari_bnf(proof)
2041 cycle_structure = eval(str(k.getattr('clgp.cyc')))
2042
/home/was/s/local/lib/python2.5/site-packages/sage/rings/number_field/
number_field.py in pari_bnf(self, certify, units)
1901 try:
1902 if certify:
- 1903 self.pari_bnf_certify()
1904 return self.__pari_bnf
1905 except AttributeError:
/home/was/s/local/lib/python2.5/site-packages/sage/rings/number_field/
number_field.py in pari_bnf_certify(self)
1934 raise TypeError, Unable to coerce number field
defined by non-integral polynomial to PARI.
1935 if not self.__pari_bnf_certified:
- 1936 if self.pari_bnf(certify=False,
units=True).bnfcertify() != 1:
1937 raise ValueError, The result is not correct
according to bnfcertify
1938 self.__pari_bnf_certified = True
/home/dmharvey/gen.pyx in sage.libs.pari.gen._pari_trap (sage/libs/
pari/gen.c:33124)()
PariError: not enough precomputed primes, need primelimit ~ (35)
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://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Major bug in GF(109)['x', 'y']
On Sep 9, 2008, at 10:20 PM, mabshoff wrote: Could a ticket be opened? #4095 it is. You all know what this means. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: pari slowness
On Jun 9, 2008, at 10:36 PM, mabshoff wrote: Okay, I can confirm that with sage 3.0.1, sage -gp has the same speed as my standalone GP build. So mostly likely the change to GMP 4.2.2 introduced a speed regression (probably the core 2 patches not being applied properly). Ok, I will investigate and made this a blocker for 3.0.3: #3388 As is the gmp.spkg with the Core2 patches and all that fun stuff is a giant mess including the OSX fixes made by William :) Let's hope MPIR is here sooner than later I just noticed that the slowness happens on amd64 as well, so probably Gaudry's patches are not being applied properly either. This is on alhambra (2.6GHz opteron): -- | SAGE Version 3.0.1, Release Date: 2008-05-05 | | Type notebook() for the GUI, and license() for information.| -- sage: x = ZZ.random_element(2^1000) sage: y = ZZ.random_element(2^1000) sage: time z = x * y CPU times: user 0.19 s, sys: 0.02 s, total: 0.21 s Wall time: 0.21 sage: time z = x * y CPU times: user 0.19 s, sys: 0.01 s, total: 0.20 s Wall time: 0.20 sage: time z = x * y CPU times: user 0.20 s, sys: 0.00 s, total: 0.20 s Wall time: 0.20 -- | SAGE Version 3.0.2, Release Date: 2008-05-24 | | Type notebook() for the GUI, and license() for information.| -- sage: x = ZZ.random_element(2^1000) sage: y = ZZ.random_element(2^1000) sage: time z = x * y CPU times: user 0.41 s, sys: 0.00 s, total: 0.41 s Wall time: 0.42 s sage: time z = x * y CPU times: user 0.41 s, sys: 0.00 s, total: 0.41 s Wall time: 0.41 s sage: time z = x * y CPU times: user 0.41 s, sys: 0.00 s, total: 0.41 s Wall time: 0.41 s 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: pari slowness
On Jul 22, 2008, at 12:35 PM, David Harvey wrote: Okay, I can confirm that with sage 3.0.1, sage -gp has the same speed as my standalone GP build. So mostly likely the change to GMP 4.2.2 introduced a speed regression (probably the core 2 patches not being applied properly). Ok, I will investigate and made this a blocker for 3.0.3: #3388 As is the gmp.spkg with the Core2 patches and all that fun stuff is a giant mess including the OSX fixes made by William :) Let's hope MPIR is here sooner than later I just noticed that the slowness happens on amd64 as well, so probably Gaudry's patches are not being applied properly either. This seems to have been fixed already in 3.0.5. Sorry for the noise. david --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sage-devel group. 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?hl=en -~--~~~~--~~--~--~---
[sage-devel] Re: does zn_poly normally take a long time to build?
On Jul 16, 2008, at 11:54 PM, tkeller wrote: I may have been imprecise. To clarify, zn_poly built, then displayed this message: Calibrating cycle counter... ok (3.84e+18) Okay, this means that zn_poly thinks your clock speed is around 3.84 billion GHz. (Yes, 3.84 * 10^18 cycles per second.) This means zn_poly thinks it's allowed to spend a bit longer (!) on the tuning process. I assume your machine is not really that fast. It's possible that either my cycle counting code is not working on your machine, or that something like getrusage is not working as I expect on your machine, or maybe some other weird timing fluke. Could you try building again, to see if it's easily reproducible? 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Sage Bug Report] Invalid polynomials generated in formal group law calculation
Hi, I don't have time to debug this now, but I want to mention that it sounds suspiciously similar to this ticket: http://sagetrac.org/sage_trac/ticket/2943 Maybe there are some clues there, but I never quite got to the bottom of it. david On Jul 17, 2008, at 8:50 AM, Hamish wrote: Dear sage-devel, I have recently come across a bug which is perhaps best summarised in the following code (I've removed a big chunk of the backtrace to make it easier to read; the full backtrace is available at the end of this message): --- BEGIN --- sage: k.a = GF(5^2, 'a') sage: EllipticCurve(k, [1,1]).formal_group().group_law(prec = 7) -- - TypeError Traceback (most recent call last) /Users/hlaw/src/ipython console in module() /Users/hlaw/sage/local/lib/python2.5/site-packages/sage/schemes/ elliptic_curves/formal_group.py in group_law(self, prec) 440 lam3 = lam2*lam 441 t3 = -t1 - t2 - \ -- 442 (a1*lam + a3*lam2 + a2*nu + 2*a4*lam*nu + 3*a6*lam2*nu)/ \ 443 (1 + a2*lam + a4*lam2 + a6*lam3) 444 inv = self.inverse(prec) [snip] /Users/hlaw/src/polynomial_element.pyx in sage.rings.polynomial.polynomial_element.Polynomial.valuation (sage/ rings/polynomial/polynomial_element.c:22641)() TypeError: The polynomial, p, must have the same parent as self. --- END --- (Note that the polynomial referred to in the TypeError is a red herring: it's an optional parameter to the valuation() method that is not being used in this case.) So the bug is being triggered in the Polynomial.valuation() method, but from what I've determined so far, it occurs because the polynomial whose valuation is being calculated is corrupted in the following sense. If p is the polynomial triggering the error, then: p.coeffs() is [0, 0, 0, 0, 0, 0, 0] p.degree() is 6 p.is_zero() is False Moreover, the error only occurs at certain precisions. For example: sage: def run_test(field, prec_bound=20): E = EllipticCurve(field, [1,1]) FG = E.formal_group() error_precisions = [] for precision in range(2, prec_bound): try: gl = FG.group_law(precision) except TypeError: error_precisions.append(precision) return error_precisions sage: run_test(GF(5^2, 'a'), 30) [5, 6, 7, 9, 11, 13, 14, 15, 17, 19, 21, 23, 25, 26, 27, 29] I have tried randomly changing the elliptic curve and the field degree, but run_test() returned exactly the same list each time. Changing the base field modifies the list a bit: sage: run_test(GF(7^2, 'a'), 30) [5, 6, 7, 9, 11, 13, 15, 17, 18, 19, 20, 21, 23, 25, 27, 29] So 14 and 26 are now gone, but 18 and 20 have been introduced. And finally, no errors occur at all if we use a prime finite field instead of a non-prime one: sage: run_test(GF(5), 30); run_test(GF(7), 30) [] [] The same basic bug occurs on the following machines: Sage 3.0.3 (upgraded from 2.11), Ubuntu Linux 8.04, x86 Sage 2.11, Ubuntu Linux 8.04, x86 Sage 3.04, Mac OS X 10.5.3, x86 The examples in this message were all calculated on the MacOSX machine. Also, I'd like to be put on the CC list of the ticket, if/when a ticket is created for this bug. Thanks in advance, Hamish. Full backtrace: sage: k.a = GF(5^2, 'a') sage: EllipticCurve(k, [1,1]).formal_group().group_law(prec = 7) -- - TypeError Traceback (most recent call last) /Users/hlaw/src/ipython console in module() /Users/hlaw/sage/local/lib/python2.5/site-packages/sage/schemes/ elliptic_curves/formal_group.py in group_law(self, prec) 440 lam3 = lam2*lam 441 t3 = -t1 - t2 - \ -- 442 (a1*lam + a3*lam2 + a2*nu + 2*a4*lam*nu + 3*a6*lam2*nu)/ \ 443 (1 + a2*lam + a4*lam2 + a6*lam3) 444 inv = self.inverse(prec) /Users/hlaw/src/element.pyx in sage.structure.element.RingElement.__mul__ (sage/structure/element.c: 8797)() /Users/hlaw/src/coerce.pxi in sage.structure.element._mul_c (sage/ structure/element.c:16614)() /Users/hlaw/src/power_series_poly.pyx in sage.rings.power_series_poly.PowerSeries_poly._mul_c_impl (sage/rings/ power_series_poly.c:3161)() /Users/hlaw/src/element.pyx in sage.structure.element.RingElement.__mul__ (sage/structure/element.c: 8797)() /Users/hlaw/src/coerce.pxi in sage.structure.element._mul_c (sage/ structure/element.c:16614)() /Users/hlaw/src/polynomial_element.pyx in sage.rings.polynomial.polynomial_element.Polynomial._mul_c_impl (sage/ rings/polynomial/polynomial_element.c:7260)() /Users/hlaw/src/polynomial_element.pyx in sage.rings.polynomial.polynomial_element.Polynomial._mul_karatsuba
[sage-devel] Re: does zn_poly normally take a long time to build?
On Jul 17, 2008, at 10:31 AM, tkeller wrote: Rebuilt 3.0.5 and didn't have any issues this time. Cycle counter gave (1.68e+09) this time around and zn_poly built in about 2 minutes or so. I also rebuilt 3.0.3 and likewise didn't have any problems. Sorry for the phantom bug report. I've been looking at the calibration code and I can see one spot where (in extremely rare circumstances) the behaviour you observed could occur. Thanks for the bug report, and let us know if it happens again! 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Sage Bug Report] Invalid polynomials generated in formal group law calculation
On Jul 17, 2008, at 9:51 AM, Hamish wrote: I don't have time to debug this now, but I want to mention that it sounds suspiciously similar to this ticket: http://sagetrac.org/sage_trac/ticket/2943 It certainly does. (I probably should have filtered the tickets with power series instead of just polynomial when I was looking through them.) The main difference seems to be that in the the present case, the base ring of the polynomial ring is exact, though the polynomial ring in question is derived from the inexact power series ring used in the calculation of the formal group law. Anyway, I get something that works if I remove the bit in the patch in ticket 2943 that uses the old way of determining __nonzero__-ness for exact base rings (i.e. now the code says a polynomial is __nonzero__ if all its coefficients are nonzero, instead of checking if the list of coefficients is non-empty). I have added a link back to this thread from the ticket. If you find out any more, please add comments to that ticket. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Epydoc API Documentation for Sage
On Jul 17, 2008, at 6:06 AM, Mike Hansen wrote: Hello all, I played around a bit with Epydoc this morning and was able to get it to produce semi-decent output for Sage (by explicitly importing sage.all at the top of the epydoc script). You can find the documentation at http://sage.math.washington.edu/home/mhansen/sage-epydoc . Hmmm looks really nice, but there's some strangeness, e.g. the documentation for next_prime() in sage.rings.arith has some weird stuff in the proof flag. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Make on sage 3.0.3 failed on flint-1.06.p3
On Jul 5, 2008, at 2:03 PM, William Stein wrote: On Sat, Jul 5, 2008 at 7:38 AM, Shing [EMAIL PROTECTED] wrote: Hi, When I try to complile sage 3.0.3, I have an error installing flint-1.06.p3. Below is the intallation.log. I am compiling on a PC running opensuse 11 and with a Athlon 1700 CPU. From the log, sage seems to think I have gcc 3.4. It says in the log: WARNING: gcc version less than 3.4.0 GCC version less than 3.4.0 Flint will not be able to compile successfully You need to install a gcc version 3.4.0. But it also says in the log gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036] (SUSE Linux) So the version detection logic must be incorrect. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Computing large Bernoulli numbers
Returning to a slightly old thread. I have implemented a new algorithm for computing large Bernoulli numbers. Running on 10 cores for 5.5 days, I computed B_k for k = 10^8, which I believe is a new record. (Recall the Mathematica blog post from April was for k = 10^7.) Essentially it's the multimodular algorithm I suggested earlier on this thread, but I figured out some tricks to optimise the crap out of the computation of B_k mod p. Patch is up for review here: http://sagetrac.org/sage_trac/ticket/3542 Preprint is here (comments welcome): http://math.harvard.edu/~dmharvey/bernmm/bernmm.pdf One data point, on a 2.6GHz opteron: sage: time x = bernoulli(10^5, algorithm=pari) CPU times: user 0.16 s, sys: 0.00 s, total: 0.16 s Wall time: 20.57 s sage: time y = bernoulli(10^5, algorithm=bernmm) CPU times: user 6.54 s, sys: 0.00 s, total: 6.54 s Wall time: 6.54 s sage: time z = bernoulli(10^5, algorithm=bernmm, num_threads=3) CPU times: user 6.54 s, sys: 0.03 s, total: 6.57 s Wall time: 2.71 s sage: x == y True sage: x == z True Timings for some bigger k: k = 10^7: PARI/GP = 75 h Mathematica = 142 h bernmm (1 core) = 11.1 h bernmm (10 cores) = 1.3 h k = 10^8: bernmm (10 cores) = 131h = 5.5 days 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: presentation about Maxima at Sage developer days
On Jun 20, 2008, at 5:42 PM, root wrote: I believe you sidestepped the question. My point is that Sage makes the claim that it will be a viable alternative to the 4Ms. In computational mathematics that is a testable claim. So test it. snip I think it would be good for someone to test Sage on those suites you suggest. It's just a question of someone offering to come forward and do the work! 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Testing futur mirror : www.sagemath.fr
On Jun 18, 2008, at 8:15 PM, Dan Drake wrote: [1]: http://blog.mozilla.com/gen/2007/02/27/the-cost-of-monoculture/ [2]: http://blogs.zdnet.com/Ou/?p=412 [3]: http://www.korealawblog.com/entry/ why_you_cant_buy_anything_on_line_in_korea_mr_foreigner Holy crap. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Pickling functions
On Jun 14, 2008, at 1:25 PM, Daniel Bump wrote:
Some code that has been proposed by Nicolas Thiery
for sage/combinat/families.py would create classes
that have as attributes dictionaries of functions.
However dumps(s) will raise an exception if s is
such a class instance.
Example: the simple reflections in a Weyl group. See:
http://groups.google.com/group/sage-combinat-devel/msg/
8b987cd471db3493?hl=en
What it boils down to is this. The following is
fine in native Python:
import pickle
def f(x): return x+1
...
pickle.dumps(f)
'c__main__\nf\np0\n.'
pickle.dumps({1:f})
'(dp0\nI1\nc__main__\nf\np1\ns.'
But if you try to run this from within Sage,
both calls to dumps() will raise exceptions.
Is this a bug in Sage?
I actually thought you couldn't really pickle functions, even in
plain python.
http://docs.python.org/lib/node317.html
Note that functions (built-in and user-defined) are pickled by
``fully qualified'' name reference, not by value. This means that
only the function name is pickled, along with the name of module the
function is defined in. Neither the function's code, nor any of its
function attributes are pickled. Thus the defining module must be
importable in the unpickling environment, and the module must contain
the named object, otherwise an exception will be raised.
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://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] weird documentation thing
http://www.sagemath.org/doc/html/ref/module-sage.rings.real-mpfr.html In Sage (as in MPFR), floating-point numbers of precision $ p$ are of the form 1251#175 , where 1252#176 , 1253#177 , and 1254#178 ; plus the special values +0, -0, +infinity, -infinity, and NaN (which stands for Not-a-Number). What does it mean for a floating point number to be of the form 1251#175? Is that supposed to be a reference to an image file? I looked at the HTML source and didn't quite understand it. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: elliptic curve division polynomials
On Jun 10, 2008, at 10:34 AM, John Cremona wrote: Problem/question 2: looking at the code in ell_generic.py I find that there are now *3* different implementations of division polys of various kinds. (1) E.division_pol = E.torsion_pol is by David Kohel (2005-04-25) and returns a polynomial in x alone, with a factor of the 2-division poly in x when m is even. (2) E.full_division_pol is William's new code (which can be asked to call the preceding when m is odd) which returns a polynomial in x and y, i.e. in the 2-variable poly ring over K, which happens to be of the form p(x) or y*p(x) where p is a poly in x alone (but belonging to K[x,y]). (3) There is code which is all commented out due to David Harvey (2006-09-24) consisting of 3 functions pseudo_torsion_polynomial(), multiple_x_numerator(() and multiple_x_denominator(). The first is the same as before for odd m but for even m just omits the factor of the 2-division poly. I like this implementation: it uses a cache, and also the user supplies their own 'x' which need not be an indeterminate. This is *very* useful since it is expensive to compute (say) the 10th division poly as a polynomial and then substitute avalue for x, it is much faster to evaluate as you go along. The last two give the numerator and denominator of the x-coordinate of m*P, i.e. of the first rational function returned by William's multiplication_by_m(). [By the way, it is easy to get the y-coordinate from the x-coordinate: if the x-coord is X(x) then the y-coord is c*y*X'(x) where c is a constant. I think the constant is m in this case (look at the invariant differential). Does anyone know why those three functions are commented out? William, why did you write your own new functions instead of using these? Can we try to clean all this up once and for all? Would you trust me to do this? I can't remember why they are commented out. However I should mention that there is yet *another* implementation of something very similar, see sage.schemes.elliptic_curves.padics, the function _multiply_point(). 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] pari slowness
Hi, This is on an 8-core 2GHz xeon running debian. (Tom Boothby's machine.) In a clean build of sage-3.0.2: sage: time x = bernoulli(4) CPU times: user 4.19 s, sys: 0.01 s, total: 4.20 s Wall time: 4.20 s sage: time x = bernoulli(4) CPU times: user 3.18 s, sys: 0.01 s, total: 3.18 s Wall time: 3.19 s sage: time x = bernoulli(4) CPU times: user 3.18 s, sys: 0.00 s, total: 3.19 s Wall time: 3.19 s sage: time x = bernoulli(4) CPU times: user 3.18 s, sys: 0.00 s, total: 3.19 s Wall time: 3.19 s Then I tried building my own PARI/GP. I first built gmp 4.2.1 with jason martin's core 2 patches. Then I built pari/gp. I get: ? # timer = 1 (on) ? x = bernfrac(4); time = 1,972 ms. ? x = bernfrac(4); time = 1,317 ms. ? x = bernfrac(4); time = 1,316 ms. ? x = bernfrac(4); time = 1,316 ms. Why is the sage version three times slower than the gp version? 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: pari slowness
On Jun 9, 2008, at 1:19 PM, mabshoff wrote: On Jun 9, 10:05 am, David Harvey [EMAIL PROTECTED] wrote: Hi, Hi David, This is on an 8-core 2GHz xeon running debian. (Tom Boothby's machine.) In a clean build of sage-3.0.2: sage: time x = bernoulli(4) CPU times: user 4.19 s, sys: 0.01 s, total: 4.20 s Wall time: 4.20 s sage: time x = bernoulli(4) CPU times: user 3.18 s, sys: 0.01 s, total: 3.18 s Wall time: 3.19 s sage: time x = bernoulli(4) CPU times: user 3.18 s, sys: 0.00 s, total: 3.19 s Wall time: 3.19 s sage: time x = bernoulli(4) CPU times: user 3.18 s, sys: 0.00 s, total: 3.19 s Wall time: 3.19 s Then I tried building my own PARI/GP. I first built gmp 4.2.1 with jason martin's core 2 patches. Then I built pari/gp. I get: ? # timer = 1 (on) ? x = bernfrac(4); time = 1,972 ms. ? x = bernfrac(4); time = 1,317 ms. ? x = bernfrac(4); time = 1,316 ms. ? x = bernfrac(4); time = 1,316 ms. Why is the sage version three times slower than the gp version? No clue. Can you actually compare the gp binary from Sage directly with the timings from your self builid binary to eliminate the problem that libPari is involved here? If the gp binary in Sage is slower by a factor of three compared to the one you build this sounds like a bug to me. But it could also be conversation overhead for example. With sage -gp, I get something *in between*: ? x = bernfrac(4); time = 3,272 ms. ? x = bernfrac(4); time = 2,260 ms. ? x = bernfrac(4); time = 2,260 ms. The banner printout is exactly the same for both gp builds: GP/PARI CALCULATOR Version 2.3.3 (released) amd64 running linux (x86-64/GMP-4.2.1 kernel) 64- bit version compiled: Jun 9 2008, gcc-4.1.2 20061115 (prerelease) (Debian 4.1.1-21) (readline v5.2 enabled, extended help available) except that my standalone build says readline not compiled in. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: pari slowness
On Jun 9, 2008, at 5:17 PM, Jonathan Bober wrote: On Mon, 2008-06-09 at 10:19 -0700, mabshoff wrote: [...] No clue. Can you actually compare the gp binary from Sage directly with the timings from your self builid binary to eliminate the problem that libPari is involved here? If the gp binary in Sage is slower by a factor of three compared to the one you build this sounds like a bug to me. But it could also be conversation overhead for example. Definitely could be conversion overhead. On my machine (warning: I'm still running the ridiculously old Sage 2.10.2) I get sage: time y = pari(4).bernfrac() CPU times: user 4.14 s, sys: 0.00 s, total: 4.14 s Wall time: 4.15 sage: type(y) type 'sage.libs.pari.gen.gen' sage: time x = Rational(y) CPU times: user 1.50 s, sys: 0.00 s, total: 1.50 s Wall time: 1.50 It looks like the conversion from sage.lib.pari.gen.gen to sage.rings.rational.Rational just converts y to a string and then parses the resulting string, which is why this takes so long. That's true, that definitely accounts for part of it. But there's still quite a big gap between the times from sage -gp and from my standalone GP build (see my followup email earlier on this thread). I wonder if we are just building GMP incorrectly. That bernfrac() routine should depend mainly on the speed of long integer multiplication and division. I am not a GP expert --- how does one generate large random integers in GP? I could try multiplying them to see how long that takes. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: pari slowness
On Jun 9, 2008, at 5:35 PM, Michael Abshoff wrote: I wonder if we are just building GMP incorrectly. That bernfrac() routine should depend mainly on the speed of long integer multiplication and division. I am not a GP expert --- how does one generate large random integers in GP? I could try multiplying them to see how long that takes. Well, I believe that out spkg-install for GMP is potentially broken since we updated to gmp 4.2.2. There are also some potential issues with pre-3.0.3 gmp.spkgs, so I am adding some explicite messages that lets you know that Jason's GMP patch was actually applied. In which version of sage did we switch to gmp 4.2.2? I will try building the previous version on this machine and compare results. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: pari slowness
On Jun 9, 2008, at 5:17 PM, Jonathan Bober wrote: On Mon, 2008-06-09 at 10:19 -0700, mabshoff wrote: [...] No clue. Can you actually compare the gp binary from Sage directly with the timings from your self builid binary to eliminate the problem that libPari is involved here? If the gp binary in Sage is slower by a factor of three compared to the one you build this sounds like a bug to me. But it could also be conversation overhead for example. Definitely could be conversion overhead. On my machine (warning: I'm still running the ridiculously old Sage 2.10.2) I get sage: time y = pari(4).bernfrac() CPU times: user 4.14 s, sys: 0.00 s, total: 4.14 s Wall time: 4.15 sage: type(y) type 'sage.libs.pari.gen.gen' sage: time x = Rational(y) CPU times: user 1.50 s, sys: 0.00 s, total: 1.50 s Wall time: 1.50 It looks like the conversion from sage.lib.pari.gen.gen to sage.rings.rational.Rational just converts y to a string and then parses the resulting string, which is why this takes so long. This is now http://trac.sagemath.org/sage_trac/ticket/3387 (this ticket does not include the discrepancy in GP timings) 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: pari slowness
On Jun 9, 2008, at 5:58 PM, William Stein wrote: On Mon, Jun 9, 2008 at 2:43 PM, David Harvey [EMAIL PROTECTED] wrote: On Jun 9, 2008, at 5:35 PM, Michael Abshoff wrote: I wonder if we are just building GMP incorrectly. That bernfrac() routine should depend mainly on the speed of long integer multiplication and division. I am not a GP expert --- how does one generate large random integers in GP? I could try multiplying them to see how long that takes. Well, I believe that out spkg-install for GMP is potentially broken since we updated to gmp 4.2.2. There are also some potential issues with pre-3.0.3 gmp.spkgs, so I am adding some explicite messages that lets you know that Jason's GMP patch was actually applied. In which version of sage did we switch to gmp 4.2.2? I will try building the previous version on this machine and compare results. The last version, so that we could build on cygwin, and also it was needed for OS X 10.5 64-bit. We will switch to mpir soon, as soon as there is a release :-) Okay, I can confirm that with sage 3.0.1, sage -gp has the same speed as my standalone GP build. So mostly likely the change to GMP 4.2.2 introduced a speed regression (probably the core 2 patches not being applied properly). 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of sqrt(2)
On Jun 4, 2008, at 7:07 AM, Bill Page wrote: Ok (and thanks also for the clarification, David). There are of course two different uses of object here: 1) object of some category, 2) Python object. All Python objects have a 'type', i.e. belong to some Python class. So in Sage 3.0.2 I observe for example: sage: type(1) type 'sage.rings.integer.Integer' sage: parent(1) Integer Ring sage: type(parent(1)) type 'sage.rings.integer_ring.IntegerRing_class' sage: category(parent(1)) Category of rings sage: type(category(parent(1))) class 'sage.categories.category_types.Rings' and sage: type(1.0) type 'sage.rings.real_mpfr.RealNumber' sage: parent(1.0) Real Field with 53 bits of precision sage: type(parent(1.0)) type 'sage.rings.real_mpfr.RealField' sage: category(parent(1.0)) Category of fields sage: type(category(parent(1.0))) class 'sage.categories.category_types.Fields' These seem consistent to me, albeit rather complex. However I am not sure I understand the following: sage: parent(IntegerRing()) type 'sage.rings.integer_ring.IntegerRing_class' sage: parent(RealField()) type 'sage.rings.real_mpfr.RealField' Could you explain why the parent of an object of some category is a type? I'm not an expert on these things any more, but I can tell you what happened back in the day (when the sage version number was slightly smaller): Only elements have real parents. Since ZZ = IntegerRing() is not an element, it doesn't have a parent. If X does not have a parent, then parent(X) returns the type of X instead. I'm not sure this is a good idea, but there it is. Of course then you're wondering why ZZ is not an element of the category of the rings. That I do not know. But you can try: sage: IntegerRing().parent() to see that IntegerRing() simply doesn't have a parent() method, which is why the global version parent(IntegerRing()) returns the type of IntegerRing() instead. One difficulty with ZZ being both a parent and an element is that Cython does not support multiple inheritance. BTW I should mention that the whole idea of parents vs types is one of the main conceptual things inherited from Magma. sorry gotta go cannot answer rest of email, hopefully someone else can 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: New Sage website
Everyone keeps saying they don't like the blue. Well, I *do* like the blue! Just my 2 cents :-) david On Jun 4, 2008, at 1:40 PM, Clement Pernet wrote: First, I really think this web site looks much better, and mature. Great job! I asked my roomate, Alan, to review it, since he's quite a bit into web app. development. Here are his comments: * in general: less pages, dont hide things 3 pages deep. everything on the site could be edited down to 5 or 6 pages. * you can try Sage online here should be either the first or second thing on the page. this is a major hook. * the blurb and links in the feature tour page should be on the first page above the icons. * search box should be on first page. get rid of separate pages. * therefore, the number of buttons reduces to 4 * rss feed should have _orange_ rss icon (people looking for RRS link get are looking for something orange) * put the try sage online link in the download section too * remove second level of navigation tabs. no one expects these to be there. instead, put all the content in the separate sub-pages in one page under their own headings. * links pages have no context. put links where they belong. if its to packages you use, put them under a packages we use heading in development section or sometime My 2 cents to the discussion are: * the blue is too blue (already said), * in the download section: the left column is way too large ; I would visually prefer a 1/3 2/3 proportion. Maybe some of these comments would involve too deep modifications to be taken into account, but I hope it will still be of any help. Cheers, Clément --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] new website
nitpicking issues. (some are more subjective than others, feel free to ignore any of the suggestions below) main page: Python based = Python-based Next to the download button, shouldn't be a space between 3.0.2 and the comma; and I don't see the need for a colon after Version inconsistent capitalisation: Quickstart - Research - Education are capitalised, documentation - support - references are not Download page: hardware platforms = hardware announcement newsletter = mailing list [I don't think the subscribe box/button should be on that page. It clutters it up unnecessarily.] Beneath Microsoft Windows, might as well get rid of VMWare Image. That's unnecessary. The process is described on the right. read additional instructions here = read these additional instructions It is currently = There is currently native port to = native port for Efforts are undertaken to make a native port possible = We are currently working on a native port. [Perhaps provide a link to the wiki page where mabshoff is coordinating efforts for this] The current VMWare Image is available and provides you with an encapsulated and solid tested system. It contains everything and needs nearly no configuration. This sounds weird to me. Perhaps it should be a separate paragraph before the one about the native port. Or perhaps it shouldn't exist at all. Under Linux: by right click = by right clicking Meanwhile, there are binary builds available = Binary builds are available. distribution specific = distribution-specific Efforts are currently done for = Progress is being made for Under source: complete source of Sage = complete source for Sage It ships together with everything it needs to compile itself and also provides all bits and pieces to develop Sage. This includes the source code of Sage, all dependencies including Python and the complete changelog in a mercurial repository. can be simplified. How about just: It ships with all dependencies including Python and the complete changelog in a Mercurial repository. read the installation guide = read the installation guide. a copy of Sage on DVD = a copy of Sage on DVD. Going back up to the Linux section, for consistency, the first line should be a link download Linux binaries. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: new website
Some more. Development page: The proclaimed mission is = Our mission is Let's be consistent with create vs creating. It's different here from the main page. I think creating is better. In the enumerated list, I would prefer n-dashes (ndash;) instead of hyphens. There is the IRC channel = There is an IRC channel Sage uses several techniques to continually improve overall software quality: = We take code quality seriously: On the search page, I find the list of examples a bit confusing. It looks like a list of headings for different types of searches you can perform. Acknowledgements page: Developing Sage benefited from financial support of numerous institutions and the work of many developers of included components. = Sage development has benefited from the financial support of numerous institutions, and the previous (and ongoing) work of many authors of included components. Acknowledgment for Supporting Sage sound weird to me. Financial and Infrastructure Support = Financial and infrastructure support. I'm not sure if infrastructure is the right word. Can't quite think of the right word now. Maybe material. Not sure. Map: Sage Developers around the World = Sage Developers around the world, or even Sage developers around the world Back to the main page: search Sage related websites = search Sage-related websites 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: new website
On the main page, why not put the mission *first*, and then afterwards put Sage is... Also, under Library, I don't know what works means. Maybe that works in deutsch, but it doesn't work in english :-). Do you mean like projects that use Sage, or tools built on top of Sage, or something along those lines? 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: new website
On Jun 4, 2008, at 6:09 PM, Harald Schilly wrote: Also, under Library, I don't know what works means. This was already a problem mentioned somewhere else. Very interesting. I looked it up in a dictionary and it is the correct translation. Maybe it is used differently? Or is the word workings better? You used it in ...and the previous (and ongoing) work of many authors of included components. I think, in German it has a broader meaning but is still the same word. I think the word must be used differently in english. There is a subtle distinction for example between the works of Gauss and the work of Gauss. The former is perhaps more like the German meaning (I'm not speaking with any knowledge of German here); it refers to the specific texts that Gauss wrote. The latter refers more generally to the activities and research in which Gauss engaged. You can also say works of art or mathematical works of the 19th century, but it sounds very strange to say works by itself without any further context. I'm not completely sure why. It's just one of those weird things. (Workings is much much worse.) What I mean is written (digital) text that has been done for, about and with Sage excluding development (howto's, papers, examples, ...) - that ends up in a collection, called library. How is this different from the Help section? 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of sqrt(2)
On Jun 3, 2008, at 10:04 PM, Robert Bradshaw wrote: How does it related to the concept of parent - which seems equally ill-defined to me? A Parent is an Object in the category of Sets, huh? Don't you mean to say something more like a parent is an object of a concrete category, i.e. a category C with a faithful functor f : C - Set, such that the elements (as understood by Sage) of the parent P are exactly the elements of f(P)? though in the context of coercion one usually assumes one can some kind of arithmetic (binary operations) on their elements. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: slightly OT: new M4RI library
On May 17, 2008, at 8:38 PM, Bill Hart wrote: Of course one can go too crazy with optimisation. No surely that never happens around here. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Computing large Bernoulli numbers
On May 6, 2008, at 12:53 PM, mhampton wrote: That certainly merits a blog post somewhere - ? On May 5, 2:02 pm, [EMAIL PROTECTED] wrote: My computation of bernoulli(10^7+4) using GP version 2.3.3 has completed in 217417011 miliseconds. That's about 2 days, 12 hours. Anybody know how I can print the thing to file? Machine: Quad-core 2.0Ghz Xeon, 1333MHz FSB, 32GB RAM. Currently, my gp session is using 4GB of RAM. You might also want to check the result using the bernoulli_mod_p_single function that I mentioned a few days ago on this thread. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Computing large Bernoulli numbers
On May 6, 2008, at 1:18 PM, William Stein wrote:
On Tue, May 6, 2008 at 10:15 AM, [EMAIL PROTECTED] wrote:
William has mentioned some congruence tests that we can perform
-- I'd like to make sure that I got the right answer before we pat
ourselves on the back too much.
David Harvey's congruence tests would be pretty good. Just choose
*any* prime p 10^7 + 10
say and compute B_{10^7+4} modulo it using David Harvey's function;
sage: p = next_prime(10^7+10)
sage: time bernoulli_mod_p_single(p, 10^7+4)
CPU times: user 0.49 s, sys: 0.00 s, total: 0.49 s
Wall time: 0.51
8087583
Pretty cool, eh?
. and the natural question is, could you then reconstruct the
actual bernoulli number, by computing it modulo sufficiently many
primes? Well, I did the estimates a few days ago, and it turns out
that the asymptotic behaviour of this proposed algorithm is pretty
much *the same* as the one using the zeta function (i.e. the one Pari
uses); they are both around n^2 log^2(n), if I'm not mistaken.
Unfortunately, I did some further tests, and even if I sped up
bernoulli_mod_p_single() by the largest factor I could conceive of,
overall it would still be maybe 50x slower than Pari. If anyone can
find an extra constant factor of 50x in this algorithm, I'd love to
hear about it.
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://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Computing large Bernoulli numbers
On May 6, 2008, at 2:12 PM, Mike Hansen wrote: I think a blog post with PARI timings and then timings for a modular dsage approach would be cool. Probably not so cool, since it would be like 50 machines vs one machine. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Computing large Bernoulli numbers
On May 6, 2008, at 2:19 PM, Mike Hansen wrote: Probably not so cool, since it would be like 50 machines vs one machine. Sure, but the Mathematica blog post is scalablity: In Mathematica, a core principle is that everything should be scalable. So in my job of creating algorithms for Mathematica I have to make sure that everything I produce is scalable. But Pari's algorithm is already parallelisable (just farm off a bunch of euler factors to each thread). The only advantage my algorithm has in scalability is that each thread needs only O(1) memory, instead of O(n log n) which would be required for Pari's algorithm. So if memory were tight, but you had lots of processors, and your n was really big, then perhaps this algorithm would win. But when I think about the actual numbers involved, the economics just don't work out. Even 80 processors is a pathetically small number, given a 50x serial slowdown in the algorithm. You would need thousands of cpus to even consider this approach. And even then, it would only be worthwhile if each cpu had very limited memory. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Computing large Bernoulli numbers
On May 2, 2008, at 2:56 PM, mhampton wrote: It takes about 30 seconds on my machine to get the 10^5 Bernoulli number. The mathematica blog says it took a development version of mathematica 6 days to do the 10^7 calc. So it would probably take some work, but we are not that badly off as is. But what about the asymptotics? I tried 10^5 and 2*10^5 and 4*10^5 and it wasn't pretty. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Computing large Bernoulli numbers
On May 2, 2008, at 3:40 PM, William Stein wrote: Also, when I tried bernoulli(10^7+2) directly in Sage there were a couple of issues that arose, since that command is much more designed for smaller input. I fixed those small issues. I guess we'll see in a week .. I hope you did: sage: x = bernoulli(10^7 + 2) and not sage: bernoulli(10^7 + 2) 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Computing large Bernoulli numbers
On May 2, 2008, at 3:43 PM, Bill Hart wrote: I think the asymptotics aren't going to go our way if we use pari. It takes 11s for 10^5 and I've been sitting here for quite a few minutes and didn't get 10^6 yet. So far I have on a 2.6GHz opteron: sage: time x = bernoulli(6) Wall time: 3.79 sage: time x = bernoulli(12) Wall time: 16.97 sage: time x = bernoulli(24) Wall time: 118.24 sage: time x = bernoulli(48) Wall time: 540.25 and I'll report back with 96 hopefully within an hour. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Computing large Bernoulli numbers
On May 2, 2008, at 3:45 PM, William Stein wrote: The complexity mostly depends on the precision one uses in computing a certain Euler product approximation to zeta and also the number of factors in the product. If you look at the PARI source code the comments do *not* inspire confidence in its correctness. I had a student give a provable bound on precision and number of factors needed and wasn't able to get anything as good as what PARI uses. Here's the funny part of the PARI code (in trans3.c): /* 1.712086 = ??? */ t = log( gtodouble(d) ) + (n + 0.5) * log(n) - n*(1+log2PI) + 1.712086; One way to check it is to use the bernoulli_mod_p_single() function, which computes B_k mod p for a single p and k, and uses a completely independent algorithm. sage: x = bernoulli(24) sage: p = next_prime(50) sage: bernoulli_mod_p_single(p, 24) 498812 sage: x % p 498812 sage: p = next_prime(10^6) sage: bernoulli_mod_p_single(p, 24) 841174 sage: x % p 841174 So I would say the answer is correct. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Computing large Bernoulli numbers
On May 2, 2008, at 4:08 PM, [EMAIL PROTECTED] wrote: Funny this should come up. William just gave a take-home midterm in which we had to predict the runtime for various computations, so I wrote some generic code to help. According to my code, and some liberal assumptions, it should take 5.1 days. I've attached the plots that show the curves I fit to some runtime data (x-axis is log (n,1.5) y-axis is seconds). Sorry, could you please say more precisely what the two axes are? I'm seeing negative time the way I interpret your statement. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: fast vs viable (offline post)
On May 1, 2008, at 2:42 PM, William Stein wrote: Optimistically, perhaps one indirect contribution in this direction is that Sage being open might make some people a little more aware of the extent to which one must never blindly trust the output of mathematical software. I think having the source code open helps *reduce* people's trust in mathematical software... which is in my opinion a good thing. In contrast, I think the approach Mathematica takes with this statement from their reference manual is bad: Nevertheless, particularly after all the testing that has been done on it, the probability that you will actually discover an error in Mathematica in the course of your work is extremely low. Doubtless there will be times when Mathematica does things you do not expect. But you should realize that the probabilities are such that it is vastly more likely that there is something wrong with your input to Mathematica or your understanding of what is happening than with the internal code of the Mathematica system itself.'' Arrrgggh, I just puked over my keyboard. William, don't you ever do that again. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Slightly OT: SCC 2008 Braid Groups
On Apr 30, 2008, at 4:50 PM, root wrote: But we've already had this discussion and it is clear that I'm completely out-in-the-weeds, talking-nonsense, and obviously have no idea how REAL-open-source-projects are done. So lets just leave it where it left off before, which is that I've simply dropped the attempt to give the benefit of experience. Hi Tim, I've been vaguely following your posts to this list over the last few weeks. I don't think you're talking nonsense, but I don't completely understand what point you are trying to make. You seem to be making the following argument, correct me if I'm wrong. You claim that the documentation of the implementations of algorithms in Sage is not good enough, in the sense that someone looking at the Sage codebase in a few years won't be able to understand what is going on. You conclude that Sage will die. The implication is that the way to fix things is for us to improve the documentation of these implementations (perhaps via literate programming or whatever), so that Sage will be more likely to succeed. But isn't the core problem simply one of limited resources? We all have limited time (fields-medallists and non-fields-medallists alike), and so there is some tradeoff between getting something to work as quickly as possible (and hence is useful NOW) and making a beautiful product which meets higher standard of scholarship (and hence is more useful LATER). I can't see any way around this tradeoff. The only thing I can see that will stop a project like Sage from dying is to keep building a steady inflow of users and contributors, so that the knowledge you refer to remains as alive as possible. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Slightly OT: SCC 2008 Braid Groups
On Apr 30, 2008, at 7:06 PM, root wrote: I WANT Sage to live. I want it to succeed. I want it to be the lingua-franca of the business so that we can all post our results in Sage at conferences. I want to be able to drag and drop your publication onto my system and have your code just work, your documentation just connect. I want to be able to not only use what you write, but to understand it so I can use it effectively. I want MMA and Maple users to write for Sage instead. Awesome. My problem is that I don't see the fundamental difference between Sage and any other system that I've touched in the past. Obviously you must see something, or you wouldn't be writing to this list :-) And I don't want this whole generation of mathematicians to do it all over again without some fundamental gain. I may be wrong that the literate documentation is the key. And I admit I'm a knuth-boy fanatic about it. My question is, what can you suggest that will make it live when others have not? A vibrant developer community. Lots of naive young people like me, who don't listen to doomsayers like you :-) 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] gens and ngens
Regarding ticket http://sagetrac.org/sage_trac/ticket/3045 can someone explain to me what the gens and ngens methods are supposed to mean? There seems to be a lot of inconsistency. For example: sage: ZZ.gens() (1,) These are the additive generators. Ditto here: sage: GF(7).gens() (1,) Okay, what about this: sage: GF(49, a).gens() (a,) That's not an additive generator. That's a generator as an algebra over the base ring (GF(7) in this case). Similarly: sage: ZZ[x, y].gens() (x, y) So is this rule that (1) If R has a base ring distinct from R, then R.gens() returns the generators over the base ring, where generator is interpreted according to what category we're working in, and (2) If the base ring of R is just R, then R.gens() returns the additive generators? That's a bit weird. I hate to think what happens if we implement, e.g. the ring of continuous functions on the interval [0, 1]. I suppose then gens needs to return some kind of uncountable generator object perhaps (excuse the pun)? 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Project
On Apr 21, 2008, at 12:09 PM, root wrote: I think you'd feel the same frustrations with Python if you compiled Python from scratch for every platform. You ship sources but assume that the python language exists and is compatible, which is not likely to be the case when 3.0 arrives. If you can assume the python language, why can't you assume the lisp language? If you can't assume the lisp language, why can you assume the python language? We do compile python from scratch on every platform. It's part of the Sage distribution. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Noncanonical coercion (finite fields)
On Apr 13, 2008, at 12:50 PM, Kiran Kedlaya wrote: Any opinions about what sage: F9.a = GF(9); F81.b = GF(81); F81(a) should return? There is no canonical answer, so it may be better to throw an exception rather than pick one of the two correct answers. But any of these would be better than the current behavior, which is to return 0. Interesting that's not what happens in my install of sage 2.11. I get: sage: F9.a = GF(9) sage: F81.b = GF(81) sage: F81(a) [.] type 'exceptions.IndexError': n=17606600 must be self.order() 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: use zip instead of 7zip for distributing the sage binary
On Apr 10, 2008, at 11:35 AM, mabshoff wrote: On Apr 10, 4:40 pm, William Stein [EMAIL PROTECTED] wrote: SNIP We should make Sage as easy or easier to install than any of Mathematica, Maple, Matlab, or Magma. I see no reason to compromise on this at all, since the goal is to provide a viable alternative to Mathematica, Maple, Matlab, and Magma. Part of this is that Sage must be as easy to install as those programs. Sage *is* easy to install provided one is capable of reading and following README.txt. All the points about computer literacy aside [insert when I was young I had to walk both ways to school uphill rant] I believe that this is a sad, sad world when somebody who is attempting to get a college education is incapable of following a simple README.txt. And I am not asking people to do anything hard here, i.e. Robert's argument that people should learn mathematics instead of CS skills does not reflect reality, but to follow an url, download a 1MB binary and install it. Other people in IRC have pointed out that my expectations of the average college student seem rather high and not grounded in reality, so I have no intention of opposing the switch to zip files for the vmware image. But it is my understanding the people at a University are supposed to acquire the skills to solve problems, i.e. become capable to approach a problem they have never solved and solve it by thinking about it. I don't want to sound like an elitist jerk [too late I guess], but if you are foiled by a 7zip archive maybe we have a case of PEBKAC :) [look it up if you don't know what that is ;)] I don't think the issue is whether or not the prospective user is capable of following instructions. The real issue is the cost-benefit analysis for the prospective user. I think there are a lot of potential users who might have vaguely heard about Sage from a colleague/teacher/whoever, and get to sagemath.org, and have to figure out what to do next. For many of these people, we now have their eyeballs for about 15 seconds. If they can't figure out how to download and start using Sage with less neurons than it takes to get distracted by the newspaper or their cup of coffee or whatever, then we lose them. The thing is, they *don't care about Sage yet*, and if the coffee smells better, they'll go for the coffee. So for this reason I advocate we push this even further. We should try to absolutely minimise the number of clicks needed to get them running Sage on their own machine. Currently on sagemath.org, they have to do the following: (1) click on download, (2) click on Microsoft Windows Binary (note that many users may not even know what binary means), (3) figure out that they need to download the zip file, i.e. click on it (note that many users at this stage might never have seen an apache-served directory listing) I reckon it needs to be WAY simpler than this. It needs to be a single click from the main page, labelled Download Sage for Microsoft Windows, which goes straight to a self-extracting installer. The contents of README.txt need to be put on the screen without even needing to click on README.txt. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: hyperlinks for Colloquy users
Yi, This sounds like a much better approach than what I did, but when I run that I get an error message about not being able to find the objc module? david On Apr 9, 2008, at 2:54 AM, Yi Qiang wrote: Hey, I thought this was a great idea but I found the patching Colloquy approach to be a bit hardcore, especially since it does the wrong things for channel urls in other channels. I whipped up a quick python plugin using Colloquy's plugin framework. To install it, just drop it into ~/Library/Application Support/Colloquy/PlugIns/ and type /reload plugins or restart Colloquy. You can get the plugin here: http://yiqiang.org/sage-devel-trac.py Cheers, Yi http://yiqiang.org On Fri, Apr 4, 2008 at 10:22 AM, David Harvey [EMAIL PROTECTED] wrote: Hi all, This message is for Sage developers who use the Colloquy IRC chat client. I have patched Colloquy so that text like #1234 gets hyperlinked to the sage trac server. Here is the patch file, which should get applied to the file Panels/ JVDirectChatPanel.m in the root of the colloquy tree (you can get the original source via svn from the main colloquy web site): http://math.harvard.edu/~dmharvey/sage-colloquy.patch Also I made a binary. I think I made it Universal. But really I have no idea what I'm doing, since I don't really know how to use XCode, but it seems to work for me (OSX 10.4.11, intel): http://math.harvard.edu/~dmharvey/Colloquy.app.zip 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: hyperlinks for Colloquy users
On Apr 10, 2008, at 1:02 AM, Yi Qiang wrote: I debugged this some more with Craig Citro and it turns out it's a bug in Colloquy itself. It seems that on Leopard system it links against Python 2.3 by default. I've recompiled it so it links against Python 2.5 if it exists and falls back to Python 2.3 if it does not (so it's still compatible on 10.4) You can find the app here: http://yiqiang.org/Colloquy.zip Follow the same instructions as in the previous email to install the plugin. Craig reported it working correctly on his machine now so I'm curious to see if anyone else has success =) So now I have to both use a patched Colloquy *and* a plugin? :-) But seriously, if this is really a colloquy bug, you should submit it to the author(s). They seem to have a pretty ferocious release schedule. I'm too tired to try it now, will try tomorrow. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: fractional ideals
On Apr 8, 2008, at 4:27 PM, Alex Ghitza wrote: Hi folks, On Sunday we had an interesting discussion on #sage-devel about the current implementation of fractional ideals in Sage. This was spurred mainly by #821, but went beyond the issues in that ticket. I am going to try to summarize the main points of the discussion, first so that we have a record of it, and also so it can continue and we can see what we can/should do about it. 1. At the moment, NumberFieldFractionalIdeal inherits from Ideal_generic, which David Harvey pointed out is *very bad*, since fractional ideals are *not ideals*. Yes, the terminology is confusing, but we don't have the luxury of convincing Kummer or whoever came up with it that it should be changed. 2. Another sketchy thing is that for a number field K, the method ideal() overrides the ring ideal method and returns 0 or a fractional ideal. Even if the objection from point 1 did not exist, this behavior is bad, because if I want to write a function that deals with ideals in rings, I would have to do something special if my ring is a number field (since ideal() does not have a consistent behavior). Here is, as far as I remember, what the irc discussion identified as preferred behavior: (a) For any ring R, R.ideal([list of elements of R]) should return the ideal of R which is generated by the elements in the list. This should in particular happen for a number field, i.e. if K is a number field then K.ideal([list of elements of K]) should return either the Principal ideal generated by 0 or the Principal ideal generated by 1. (b) mathematically speaking, a fractional ideal is a rank one projective module over a Dedekind domain R; equivalently, it is a nonzero finitely-generated R-submodule of the fraction field K=Frac(R). This latter description might be more amenable to computation. I don't think we have Dedekind domains in Sage, so maybe we can just have this work in the main area of application (algebraic number theory), by having fractional ideals in number fields. So if O is an order in a number field K, we would like O.fractional_ideal([list of elements of K]) to return the fractional ideal of O generated by the elements in the list. ~ For convenience, we might also want K.fractional_ideal([list of elements of K]) to be an alias for OK.fractional_ideal([list of elements of K]), where OK is the ring of integers of K. Just getting all of this straightened out for rings of integers would already be a serious but very worthwhile endeavor. Whoever was around #sage-devel when this was going on, please correct anything that I might have misrepresented. Everybody else, please comment! Alex, Strongly support everything you've said here, and thanks for taking the time to write this summary. (I'm slightly concerned about what should happen for non-maximal orders, but I can't quite remember how this is supposed to work mathematically) 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] trac is down....
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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] hyperlinks for Colloquy users
Hi all, This message is for Sage developers who use the Colloquy IRC chat client. I have patched Colloquy so that text like #1234 gets hyperlinked to the sage trac server. Here is the patch file, which should get applied to the file Panels/ JVDirectChatPanel.m in the root of the colloquy tree (you can get the original source via svn from the main colloquy web site): http://math.harvard.edu/~dmharvey/sage-colloquy.patch Also I made a binary. I think I made it Universal. But really I have no idea what I'm doing, since I don't really know how to use XCode, but it seems to work for me (OSX 10.4.11, intel): http://math.harvard.edu/~dmharvey/Colloquy.app.zip 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: your opinions about 0.digits()
On Apr 3, 2008, at 10:05 AM, Joel B. Mohler wrote: I intentionally made 0.digits() return [] because that seems to me the most consistent mathematical thing to do. +1 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: bug in factoring over number fields?
This is now http://trac.sagemath.org/sage_trac/ticket/2780 david On Apr 2, 2008, at 12:57 PM, John Cremona wrote: You are right. As a list, F has three elements of which the first is (2,1) -- i.e. 2 to the power 1 -- but when the list is converted to a Factorization type this first factor is left alone instead of being converted into the __unit part. John On 02/04/2008, David Harvey [EMAIL PROTECTED] wrote: Is the following a bug? sage: K.a = NumberField(x^2 + 1) sage: R.y, z = PolynomialRing(K) sage: f = 2*y^2 + 2*z^2 sage: F = f.factor(); F 2 * (y + (-a)*z) * (y + a*z) sage: F.unit_part() 1 Shouldn't the unit part be 2? It seems to be listing 2 as a bona fide factor. (This was reported by Genya Zaytman.) 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] multivariate polys over residue fields of number fields are broken
This example from Genya Zaytman: sage: F1.u = NumberField(x^6 + 6*x^5 + 124*x^4 + 452*x^3 + 4336*x^2 + 8200*x + 42316) sage: reduct_id = F1.factor_integer(47)[0][0] sage: Rf = F1.residue_field(reduct_id) # = GF(47^3) sage: R1.X,Y = PolynomialRing(Rf) sage: ubar = Rf(u) sage: I = ideal([ubar*X+Y]) sage: I.groebner_basis() [boom] Is this supposed to work? It's just a multivariate poly over a finite field. I've put it up at: http://trac.sagemath.org/sage_trac/ticket/2789 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Crash in quo_rem
On Apr 1, 2008, at 4:53 AM, mabshoff wrote: On Apr 1, 10:41 am, shreevatsa [EMAIL PROTECTED] wrote: Someone else was trying to do something, and I tried something and got a crash; mabshoff asked me to post a backtrace. (So if it is very long, don't blame me ;-)) This is probably invalid mathematics that should raise an exception, but it causes a crash instead on my OS X 10.4. The other person also had this problem on Linux. mabshoff speculated it is a 32-bit/64-bit issue, since it raises an exception for him. Code: K.x=QQ['X']; p=EuclideanDomainElement(K); q=EuclideanDomainElement(K); (x^3+p*x+q).quo_rem(3*x^2+p) Wait a second if I type sage: K.x = QQ['X'] sage: p = EuclideanDomainElement(K) what is this supposed to even mean? What is p supposed to be here? I get sage: p Generic element of a structure I think the __init__ call gets redirected to Element.__init__, which just sets the parent. In my opinion, this constructor call should be disallowed somehow. Unless there's something about the new coercion model that I don't know. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Fwd: Multivariate Polynomial Factoring is Broken
Begin forwarded message: From: Genya Zaytman [EMAIL PROTECTED] Date: March 31, 2008 1:15:21 PM EDT To: David Harvey [EMAIL PROTECTED] Subject: Fwd: Multivariate Polynomial Factoring is Broken Begin forwarded message: From: Genya Zaytman [EMAIL PROTECTED] Date: March 31, 2008 1:14:39 PM EDT Subject: Multivariate Polynomial Factoring is Broken sage: version() 'SAGE Version sage-2.11, Release Date: 2008-03-30' sage: q = 1073741789 sage: T.aa, bb = PolynomialRing(GF(q)) sage: f = aa^2 + 12124343*bb*aa + 32434598*bb^2; f aa^2 + 12124343*aa*bb + 32434598*bb^2 sage: f.factor() (32434598) * (16373350*aa^2 + 437239695*aa*bb + bb^2) sage: g = (32434598) * (16373350*aa^2 + 437239695*aa*bb + bb^2); g aa^2 - 49344938*aa*bb + 32434598*bb^2 sage: f == g False So basically, in the example above, we factor a homogeneous degree 2 polynomial in two variables, multiply it back out and get a different answer. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: polynomials: cyclotomic, sparse etc
On Mar 31, 2008, at 6:09 PM, William Stein wrote: Relevant code: [snip] To profile this properly, you shouldn't do it just at powers of ten, since the running time will depend heavily on the factorisation pattern of n. I guess you should do some examples with lots of small prime factors, examples with high prime powers, examples with just a prime, etc. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: polynomials: cyclotomic, sparse etc
On Mar 31, 2008, at 3:43 PM, John Cremona wrote:
There was some discussion a week or so ago about a more efficient
implentation of cyclotomic polynomials, which led to trac#2654. I
have tried various alternatives of the prototype code posted there,
finding that the speed varied enormously as a result of
trivial-seeming changes.
The key operation needed is to replace f(x) by f(x^m) for various
positive integers m, where f is an integer polynomial. Doing
{{{
f = f(x**m)
}}}
was very slow, especially for large m. Faster is to apply this
function:
{{{
def powsub(f,m):
assert m0
if m==1: return f
g={}
d=f.dict()
for i in d:
g[m*i]=d[i]
return f.parent()(g)
}}}
Is there a better way? And is this operation needed elsewhere, in
which case the function should be available generally?
I thought of using sparse polynomials, but the algorithm also needs
exact polynomial division whcih (as far as I can see) is not available
for sparse integer polys.
Suggestions welcome, so we can put a decent patch in for this
important function!
Perhaps if you have a bound for the size of the coefficients you
could do a modular approach. Work mod N where the coefficients are
guaranteed to be at most N. Usually I guess N will fit into a single
word, so the polynomial arithmetic will be much faster than working
over ZZ.
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://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: polynomials: cyclotomic, sparse etc
On Mar 31, 2008, at 8:18 PM, Robert Bradshaw wrote: By the way, I just did some cyclotomic polynomial benchmarking in on Intel Core 2 Duo 2.6Ghz laptop. Here are the results: n| Sage 2.11 | newcyc at #2654 | PARI | Magma 10^5 | 1.29 | 0.37 | 1.24 | 0.02 10^6 | ? | 32.89 | 123.8 | 0.20 10^7 | ? | ? | ?| 2.37 Magma crushes everything else yet again... Fixed up the ZZ[x] constructor, now we crush Magma (I don't feel bad taking credit 'cause I wrote the original cyclotomic coefficient code). sage: time f = cyclotomic_polynomial(10^5) CPU times: user 0.00 s, sys: 0.00 s, total: 0.00 s Wall time: 0.00 sage: time f = cyclotomic_polynomial(10^6) CPU times: user 0.01 s, sys: 0.01 s, total: 0.02 s Wall time: 0.02 sage: time f = cyclotomic_polynomial(10^7) CPU times: user 0.15 s, sys: 0.08 s, total: 0.22 s Wall time: 0.24 sage: time f = cyclotomic_polynomial(next_prime(10^5)) CPU times: user 0.05 s, sys: 0.01 s, total: 0.05 s Wall time: 0.06 sage: time f = cyclotomic_polynomial(ZZ.random_element(10^5, 10^6)) CPU times: user 0.02 s, sys: 0.00 s, total: 0.03 s Wall time: 0.06 http://trac.sagemath.org/sage_trac/ticket/2654 mate that's awesome. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Trac Guidelines are now in the Wiki
On Mar 30, 2008, at 6:31 AM, mabshoff wrote: Hello folks, there have been a large, nebulous set of rules regarding how things are done in trac, patch review and merging and the Sage development process in general. Now I finally took the time to clear those up and I put a *draft* of the guidelines up at http://wiki.sagemath.org/TracGuidelines What I wrote there is obviously not the final version and none of the rules are written in stone. I would actually like a discussion about the rules to clear any potential issue where things are either wrong or unclear. I consider what I wrote down the consensus from having done releases for the last four months, but even I do make mistakes ;) I am working on additional sections on workflow and so on. I believe that eventually the content of that Wiki page should go into the documentation or that at least a link from the official doc should point to that wiki page. On a quick skim-read, I found the Sage Specific paragraph very confusing. Are you trying to say that if someone makes up their own version of Sage that ships different versions of packages to the ones we normally ship, then they are on their own? Or something else? 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: interact versus manipulate
On Mar 8, 2008, at 10:18 AM, William Stein wrote: I'm trying to decide if Sage's new mathematica manipulate like functionality should be called manipulate or interact. [...] Thoughts about the above names: 1. Mathematica calls this command Manipulate, so if we call it manipulate, then the name will be immediately familiar to mathematica users, and we benfit from them learning it more easily as well (since it can do much the same thing). Also more likely to get sued. 2. Manipulate sounds sinister (as my wife pointed out rather strongly). 3. Interact sound very positive and non-sinister, but perhaps doesn't have quite the same ring to it as manipulate. 4. Interact is shorter, which is a plus. Well they also mean different things. Manipulate means the user is in control, and the computer is just doing what it's being told to do. It's more like driving a car. Interact means it's more like a conversation, with information flowing in both directions. The problem with interact is that you're *always* interacting with sage, this is just a different type of interaction, a bit more physically intuitive. Here are some other words I found in an online thesaurus (not to be taken too seriously) operate maneuver modify activate guide wield steer drive tamper mangle knead adjust mutate modulate alter metamorphose morph renovate transform perturb animate vivify Well I never even heard of vivify before. Another option might be to try to come up with a word that emphasises the controls themselves, like lever or slider or something. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: interact versus manipulate
On Mar 8, 2008, at 10:53 AM, David Harvey wrote: I'm trying to decide if Sage's new mathematica manipulate like functionality should be called manipulate or interact. Oh and by the way, it looks way cool. I'm looking forward to playing with it. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Doc Days
On Mar 6, 2008, at 1:01 PM, William Stein wrote: Before we can release Sage-3.0 the doctest coverage must reach 50%. This is one of the more difficult goals for Sage-3.0. Thus I propose that we have a Sage Doc Days this Sunday. Whose interested in helping? Sure. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] exact numerical integration
I tried doing some integrals today and the output doesn't make much sense to me: sage: f = e^(-x^2) sage: f.integrate(x, 0, 0.1) 2066*sqrt(pi)/36741 sage: f.integrate(x, 0, 1/10) sqrt(pi)*erf(1/10)/2 H. Does this mean erf(1/10) is a rational number? That's a little surprising to me. In fact: sage: RR(f.integrate(x, 0, 0.1)) 0.0996676643523801 sage: RR(f.integrate(x, 0, 1/10)) 0.0996676642903363 What's going on here? 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Fwd: sage-devel exact numerical integration
Begin forwarded message: From: Andrzej Chrzęszczyk [EMAIL PROTECTED] Date: March 5, 2008 6:23:53 PM EST To: [EMAIL PROTECTED] Subject: sage-devel exact numerical integration Dear David Try sage: maxima_console() (%i1) integrate(%e^(-x^2),x,0,0.1); ... `rat' replaced .05623145800914245 by 2066/36741 = .05623145804414686 2066 sqrt(%pi) (%o1) -- 36741 then you will see that (behind the scene) maxima replaces more accurate result .05623145804414686 sqrt(%pi) by the less accurate one: 2066 sqrt(%pi)/36741 (default maxima behaviour) Your exact calculations are OK but why do you mix the exact-inexact. Pure numerical version using GSL: sage: numerical_integral(lambda x:e^(-x^2),0,-.1) (-0.099667664290336327, 1.1065333570574191e-15) is in a good accordance with your exact calculations Andrzej Chrzeszczyk (I'm not in sage-devel so I'm using your e-mail adress, I hope You will excuse me) Okay, I can see this makes sense from within Maxima, since you get to see the replacement message. But in Sage, it's really terrible! When I do sage: f = e^(-x^2) sage: f.integral(x, 0, 0.1) 2066*sqrt(pi)/36741 I have absolutely no idea what is going on in the background. It could be maxima, or sympy, or some other library that someone plugged in, or who knows what. How am I supposed to tell that 2066*sqrt(pi)/36741 is not an exact answer? Since it contains sqrt(pi), it's very suggestive that it's supposed to be exact. Another example: if I do sage: f = x*e^(2*x) sage: f.integral(x, 0, 1) e^2/4 + 1/4 Is that an exact answer? Or it just close enough to e^2/4? What use is the answer if I can't tell? 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] trac is down.....
Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /sage_trac/. Reason: Error reading from remote server ? 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] polynomial_dense_modn_ntl and all that
Currently in sage.rings.polynomial we have the following class hierarchy: Polynomial Polynomial_dense_modn Polynomial_dense_modn_ntl_zz Polynomial_dense_modn_ntl_ZZ Polynomial_dense_modp The implementations are via some weird combination of direct NTL access and libs.ntl. Is there eventually supposed to be Polynomial_dense_modp_ntl_zz and Polynomial_dense_modp_ntl_ZZ as well? Currently, if I do PolynomialRing(Integers(7)), it's apparently implemented via ZZ_pX (via libs.ntl!), but if I do PolynomialRing(Integers(1000)), it's implemented via zz_pX. So we get weird things like: sage: R.x = PolynomialRing(Integers(7)) sage: f = R([ZZ.random_element() for _ in range(100)]) sage: timeit(g = f*f) 625 loops, best of 3: 168 µs per loop but: sage: R.x = PolynomialRing(Integers(100)) sage: f = R([ZZ.random_element() for _ in range(100)]) sage: timeit(g = f*f) 625 loops, best of 3: 26.2 µs per loop i.e. it's six times faster if the modulus is composite. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: harmonizing derivatives of symbolic expressions and polynomials
After hearing some ideas on IRC regarding the derivatives mess, in this email I propose a plan. It's rough around the edges. Comments welcome. CURRENT SITUATION There are currently at least 18 different functions for differentiation in Sage, attached to polynomials, power series, symbolics, and other things. (See my previous email for a complete list.) There are about 4 diff, 12 derivative, one differentiate, and sometimes (but not always) these names are aliases to each other. I count six different call signatures (all derivatives replaced by diff in the following list): def diff(self): mainly for univariate polynomial and power series types. def diff(self, verbose=None): only in the sage.functions.elementary module. All doctests are switched off on this file. The documentation says that this function *integrates* things! The verbose flag seems to be something passed to maxima. def diff(self, *args): only in calculus.calculus.SymbolicExpression. This is the most powerful version, and is the closest to what I want to eventually support everywhere. def diff(f, *args, **kwds): only in calculus.functional. This is a global, and just dispatches to the diff method on f. def diff(self, variable, have_ring=False): in the libsingular multivariate polynomial code, and also mysteriously crops up in polynomial_modn_dense_ntl.pyx. The parameter have_ring seems to be ignored everywhere, and somewhere claims that it is needed for compatibility reasons. But I can't figure out what this means. def diff(self, var='x', n=1): only in interfaces.maxima.MaximaElement. It means differentiate n times with respect to x. Note that the variable is supplied as a *string*. We might want to leave this one out of the discussion; I guess here the diff function is supposed to conform to maxima semantics (about which I know nothing) rather than fit into the sage object model. There are three open tickets on this issue: http://trac.sagemath.org/sage_trac/ticket/756 (patch is problematic) http://trac.sagemath.org/sage_trac/ticket/753 (not much interesting here) http://trac.sagemath.org/sage_trac/ticket/1578 (there's a patch here, might need to get superseded, sorry Nick) There are two separate issues here: function naming, and function signatures. The former is much simpler, so I'll discuss that first. FUNCTION NAMING I propose that we deprecate differentiate. I propose that we use diff as the basic name, and have derivative as an alias for any object supporting diff. I propose that there be a lower-level function _diff with a simpler signature, see below. FUNCTION SIGNATURES Here is an approximation to what I would like to see. Any object F supporting differentiation should have a function _diff (def or cpdef) taking at least one argument var=None. It can have additional arguments, but these must be optional. For example: def _diff(self, var=None) def _diff(self, var=None, have_ring=False) def _diff(self, var=None, verbose=False) If var is supplied, it should be a variable object (for example, a symbolic variable, or a generator of a polynomial ring). It need not lie in the parent of F. Examples: * If F is in S[x] for some ring S, and you call F._diff(x), you get what you expect. * If F is in S[x] for some ring S, and you call F._diff(y), then G._diff(y) gets called for each coefficient of F. * If F is in the symbolic ring, then var can be any symbolic variable. If var is None, the object makes a decision about the default variable and uses that. For example: * a univariate polynomial or power series will differentiate w.r.t. the generator. * a symbolic expression containing precisely one variable will use that variable. * a multivariate polynomial will raise an exception. * a symbolic expression containing more than one variable will raise an exception. Now we come to the diff method. It must have an *args-style argument, which must be interpreted according to the following list of examples (which is almost clear enough to serve as a specification :-)): F.diff(): equivalent to F._diff(None) F.diff(2): equivalent to F._diff(None)._diff(None) F.diff(x): equivalent to F._diff(x) F.diff(x, 3): equivalent to F._diff(x)._diff(x)._diff(x) F.diff(x, y): equivalent to F._diff(x)._diff(y) F.diff(x, 3, y, 2, z): equivalent to F._diff(x)._diff(x)._diff (x)._diff(y)._diff(y)._diff(z) F.diff(2, x): equivalent to F._diff(None)._diff(None)._diff(x) [this one currently causes an infinite loop for symbolic objects!] F.diff([x, y, z]): equivalent to F._diff(x)._diff(y)._diff(z) F.diff((x, y, z)): equivalent to F._diff(x)._diff(y)._diff(z) For the list and tuple versions, it must be the only parameter, and repetition counts are not allowed. When I say equivalent in the above descriptions, I don't mean it literally has to call _diff that way, I just mean the behaviour should be equivalent.
