[sage-devel] Re: interactive widgets in the notebook
On Nov 17, 2007, at 7:41 PM, William Stein wrote: > I'm pretty excited about this! I think it would be extremely > amazingly > useful if you could make up some more examples like this one > > sage: a = Slider(1,10) > sage: plot(sin(a()*x),-3,3) Why not just > plot(sin(a*x),-3,3) instead of > plot(sin(a()*x),-3,3) ? david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sage-2.8.13 release cycle: request for reviews
On Nov 18, 2007, at 4:16 AM, Robert Bradshaw wrote: >> #1130 > > This seems to rely on an earlier patch. (#1120?) See comments on trac. I'm very concerned about this patch. It is not the case that the LCM of the orders of all elements of E(GF(q)) will equal the order of E(GF (q)). I haven't tried the code, but if I understand the code correctly, it will go into an infinite loop on such cases, and it may well give incorrect results in other cases. For example: sage: K. = GF(5^3) sage: K.polynomial() a^3 + 3*a + 3 sage: E = EllipticCurve([3*a^2 + 2, 2*a + 4]) sage: E Elliptic Curve defined by y^2 = x^3 + (3*a^2+2)*x + (2*a+4) over Finite Field in a of size 5^3 sage: LCM([P.order() for P in E.points()]) 32 sage: len(E.points()) 128 david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sage-2.8.13 release cycle: request for reviews
On Nov 18, 2007, at 8:49 AM, Martin Albrecht wrote: > > On Sunday 18 November 2007, David Harvey wrote: >> On Nov 18, 2007, at 4:16 AM, Robert Bradshaw wrote: >>>> #1130 >>> >>> This seems to rely on an earlier patch. (#1120?) See comments on >>> trac. >> >> I'm very concerned about this patch. It is not the case that the LCM >> of the orders of all elements of E(GF(q)) will equal the order of E >> (GF >> (q)). I haven't tried the code, but if I understand the code >> correctly, it will go into an infinite loop on such cases, and it may >> well give incorrect results in other cases. > > Yes, it should not go in, my bad, sorry. I quickly hacked to > together the > algorithm in "Elliptic Curves" by Lawrence Washington and > apparently screwed > up badly on the way. He writes: > > 7. If we are looking for the #E(F_q), then repeat steps (1)-(6) > [finding the > order of a point, malb] with randomly chosen points in E(F_q) until > the > greatest common multiple of the orders divides only one integer N > with q + > 1 -2*sqrt(q) <= N <= q + 1 + 2*sqrt(q). Then N = #E(F_q). > > Apparently I overread the 'divides' part. Also, what is a > 'greatest common > divisor'? I still don't believe this algorithm. Look at this example: sage: K. = GF(3^4) sage: K.polynomial() a^4 + 2*a^3 + 2 sage: E = EllipticCurve(K, [2*a^2 + 2*a + 2, 2*a^3 + 2*a + 1]) sage: points = E.points() sage: len(points) 100 sage: LCM([P.order() for P in points]) 10 The hasse bound says the the number of points must be in [64, 100]. But if the best we can do is show divisibility by 10, that's not enough information: it could be 70, 80, 90, or 100. Does Washington place any other restrictions on the finite field or on the curve? david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sage-2.8.13 release cycle: request for reviews
On Nov 19, 2007, at 4:55 AM, Martin Albrecht wrote: >> I still don't believe this algorithm. >> >> Look at this example: >> >> sage: K. = GF(3^4) >> sage: K.polynomial() >> a^4 + 2*a^3 + 2 >> sage: E = EllipticCurve(K, [2*a^2 + 2*a + 2, 2*a^3 + 2*a + 1]) >> sage: points = E.points() >> sage: len(points) >> 100 >> sage: LCM([P.order() for P in points]) >> 10 >> >> The hasse bound says the the number of points must be in [64, 100]. >> But if the best we can do is show divisibility by 10, that's not >> enough information: it could be 70, 80, 90, or 100. >> >> Does Washington place any other restrictions on the finite field or >> on the curve? > > Hi David, > > I cannot see any restriction placed on the curves or the fields > used. Justin > pointed me to the errate for Washington's book but it only contains > the > remark, that the greatest common multiple is indeed the least common > multiple. Revisiting the group structure of elliptic curves I now > also cannot > see why this algorithm would work: the group of points of an > elliptic curve > over a finite field is either isomorphic to Z_n or Z_n1 + Z_n2 > where n1 | n2 > (also from Washington's book). In the later case we'll have points > of orders > n1 and n2 and their LCM will be n2. > > So the trac ticket should be invalidated. > > Does this sound about right? Yeah. So I guess either you have to look at John Cremona's code, figure out how difficult it would be to wrap, or look up another algorithm and implement that instead. Further down the road, Drew Sutherland is thinking about writing a C+ + library for computing things like orders, exponents, structures of generic abelian groups. Basically you give it a "black box" that knows how to add group elements, invert group elements, produce the identity, and produce random elements, and it efficiently works out the structure of the group, etc. No firm plans yet though I'm meeting up with him next week to discuss this. It will be some time before it's written and wrapped in sage. david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sage-2.8.13 release cycle: request for reviews [abelian groups]
On Nov 19, 2007, at 6:59 AM, David Joyner wrote: >> Further down the road, Drew Sutherland is thinking about writing a C+ >> + library for computing things like orders, exponents, structures of >> generic abelian groups. Basically you give it a "black box" that >> knows how to add group elements, invert group elements, produce the >> identity, and produce random elements, and it efficiently works out >> the structure of the group, etc. No firm plans yet though I'm > > How do you produce a random element without knowing the > generators of the group? And, for an abelian group, the > generators give you the "invariants" quickly don't they? Oh boy you guys have exhausted my meagre knowledge on this subject pretty quickly :-) I think the idea is supposed to be that part of the definition of the black box is that it can produce random elements, regardless of whether you know the generators. So for example, suppose our group is the multiplicative group of Z/NZ, for some large N whose factorisation we don't know. It's pretty easy to produce random elements of this group (or at least, every time you write down a random integer in [0, N), you have either found a random element, or can easily find a non-trivial factor of N by taking the gcd with N). But it's very hard to find generators (should be roughly equivalent to factoring N?). And yes, once you have the generators, I guess you have everything else very easily. david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sage-2.8.13 release cycle: request for reviews [abelian groups]
On Nov 19, 2007, at 10:10 AM, David Joyner wrote: >> I think the idea is supposed to be that part of the definition of the >> black box is that it can produce random elements, regardless of >> whether you know the generators. So for example, suppose our group is >> the multiplicative group of Z/NZ, for some large N whose >> factorisation we don't know. It's pretty easy to produce random >> elements of this group (or at least, every time you write down a >> random integer in [0, N), you have either found a random element, or >> can easily find a non-trivial factor of N by taking the gcd with N). >> But it's very hard to find generators (should be roughly equivalent >> to factoring N?). > > > Okay. But this raises another (possibly dumber) question. Say > N is the product of 2 very large primes. In the case of G = > ZZ/NZZ, addition, inversion and random elements can be produced > in polynomial time I asume. Yes. (In fact, almost linear time.) > Knowing the group structure of G, ie > the invariants, is tantamount to knowing the factorization of N, > isn't it? Yes. > If "yes", then what does "efficiently works" mean? "Efficiently works" means that it has a very efficient implementation of baby-step/giant-step and various algorithms built on top of that. Of course this is a terrible algorithm for factoring integers, it's not even sub-exponential, in the case of two large prime factors. With the group Z/NZ, all the best algorithms take advantage of extra structure. But if you have a "generic" group where you don't know much else about the structure --- all you know is how to add and invert --- then baby-step/giant-step is pretty much the best you can do. Drew's thesis makes good reading on this topic: http://groups.csail.mit.edu/cis/theses/sutherland-phd.pdf david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: writing a new class
On Nov 20, 2007, at 7:03 AM, Jason Grout wrote: > Hi everyone, > > I have a simple question: I'm trying to write a new class in a new > file. > How do I get that file to show up in Sage? In this case, I'm trying > to write a menu.py file under the sage/server/notebook/widgets > directory > (a new directory). But when starting up SAGE with sage -br, it > doesn't > ever say anything about my file and I can't import my file like a > normal > Sage object (i.e., from sage.server.notebook.widgets import menu). Someone who understands the sage build system will probably give you a better answer in a moment but since I'm already awake You might need to add 'sage.server.notebook.widgets' near the bottom of setup.py. That script copies files into the place where SAGE knows where to find them. david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] abelian groups
Hi all, I'd like to discuss this abelian group thing a bit further, from the point of view of design issues rather than algorithms. Currently in SAGE the situation appears to be the following. An AbelianGroup represents a (not necessarily finite) abelian group whose structure is *known*; i.e. to even create the group object, you need to specify generators and invariants. In fact, even the parent class Group derives from ParentWithGens, so it seems to be impossible to define a "group" whose generators are unknown. What I want to be able to do is create an object representing an abelian group whose structure is *not* a priori known, i.e. is expensive to compute. This is analogous to, for example, creating a matrix by specifying the entries, and then later on asking for other information like the rank, which is an expensive computation, and is subsequently cached. The main example I'm interested in at the moment is: * The group of K-rational points on a jacobian of an algebraic curve over k, where k and K/k are finite fields. Other examples: * The class group of a number field. * The multiplicative group of Z/nZ. * Like the Jacobian example above, but with the fields not finite (e.g. the rational points on an elliptic curve over Q) In these examples, it is easy to describe the group law, and it is relatively easy to write down some elements of the group, but it is difficult (or even impossible!) to compute the structure of the group. Consider the example of an elliptic curve E over a finite field k. Currently, when I call E.abelian_group(), it tries to compute the structure and return that as an AbelianGroup: sage: F = GF(17) sage: E = EllipticCurve(F, [2, 5]) sage: E.abelian_group() (Multiplicative Abelian Group isomorphic to C18, ((5 : 2 : 1),)) But I would like to be able to call something like E.abstract_abelian_group() and have it just return something like an AbstractAbelianGroup object, whose elements are something like AbstractAbelianGroupElements. This operation doesn't attempt to compute the group structure at all. The elements should remember that they came from that elliptic curve, and I should be able to create elements (by specifying their co-ordinates), and I should be able to perform arithmetic on elements. The AbstractAbelianGroup class should then have generic implementations of things like finding orders of elements, computing the exponent of the group, computing the structure of the group, which are then cached. (The reason I'm starting this thread at all is because I want to come up with a sane way to put these kind of generic group algorithms into SAGE.) Somehow at the moment in SAGE it's very difficult to separate the "group structure" from the "elliptic curve" structure. For example, suppose I have an elliptic curve over Q, and I want to work with points defined over some number field K/Q. Currently I think the only option I have is to base extend the curve to K, because points need to "belong" to the curve. But mathematically that shouldn't be necessary; I should be able to talk about K-valued points of a curve over Q. If I base-extend to K, I lose the information that the curve was really defined over Q (which might make certain computations easier). So what I would like to be able to do is call E.group_over_field(K) which returns an abstract abelian group. Maybe what I really want is a "ParentWithoutGens" base class :-) I'm really unsure of how to proceed with this. Especially since there are difficult coercion issues lurking in the background. Any thoughts would be most appreciated. david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: abelian groups
On Nov 22, 2007, at 10:25 AM, William Stein wrote: > > On Nov 22, 2007 6:53 AM, David Joyner <[EMAIL PROTECTED]> wrote: > \> On Nov 22, 2007 9:35 AM, David Harvey > <[EMAIL PROTECTED]> wrote: >>> >>> Hi all, >>> >>> I'd like to discuss this abelian group thing a bit further, from the >>> point of view of design issues rather than algorithms. >>> >>> Currently in SAGE the situation appears to be the following. An >>> AbelianGroup represents a (not necessarily finite) abelian group >>> whose structure is *known*; i.e. to even create the group object, >>> you >>> need to specify generators and invariants. In fact, even the parent >>> class Group derives from ParentWithGens, so it seems to be >>> impossible >>> to define a "group" whose generators are unknown. >>> >>> What I want to be able to do is create an object representing an >>> abelian group whose structure is *not* a priori known, i.e. is >>> expensive to compute. This is analogous to, for example, creating a >>> matrix by specifying the entries, and then later on asking for other >>> information like the rank, which is an expensive computation, and is >>> subsequently cached. > > You should make an AbstractAbelianGroup class that derives from > ParentWithBase. Hmmm but wouldn't it make more sense for AbelianGroup (i.e. the currently implemented one) to derive from AbstractAbelianGroup? i.e. an AbelianGroup is an AbstractAbelianGroup where we happen to know the structure, and so can implement things like order, exponent etc more efficiently? I guess then you have problems with multiple inheritance, since you want AbelianGroup to inherit from both AbstractAbelianGroup and ParentWithGens, both of which originally come from ParentWithBase. That's most unfortunate. david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] abelian groups
Hi all, I'd like to discuss this abelian group thing a bit further, from the point of view of design issues rather than algorithms. Currently in SAGE the situation appears to be the following. An AbelianGroup represents a (not necessarily finite) abelian group whose structure is *known*; i.e. to even create the group object, you need to specify generators and invariants. In fact, even the parent class Group derives from ParentWithGens, so it seems to be impossible to define a "group" whose generators are unknown. What I want to be able to do is create an object representing an abelian group whose structure is *not* a priori known, i.e. is expensive to compute. This is analogous to, for example, creating a matrix by specifying the entries, and then later on asking for other information like the rank, which is an expensive computation, and is subsequently cached. The main example I'm interested in at the moment is: * The group of K-rational points on a jacobian of an algebraic curve over k, where k and K/k are finite fields. Other examples: * The class group of a number field. * The multiplicative group of Z/nZ. * Like the Jacobian example above, but with the fields not finite (e.g. the rational points on an elliptic curve over Q) In these examples, it is easy to describe the group law, and it is relatively easy to write down some elements of the group, but it is difficult (or even impossible!) to compute the structure of the group. Consider the example of an elliptic curve E over a finite field k. Currently, when I call E.abelian_group(), it tries to compute the structure and return that as an AbelianGroup: sage: F = GF(17) sage: E = EllipticCurve(F, [2, 5]) sage: E.abelian_group() (Multiplicative Abelian Group isomorphic to C18, ((5 : 2 : 1),)) But I would like to be able to call something like E.abstract_abelian_group() and have it just return something like an AbstractAbelianGroup object, whose elements are something like AbstractAbelianGroupElements. This operation doesn't attempt to compute the group structure at all. The elements should remember that they came from that elliptic curve, and I should be able to create elements (by specifying their co-ordinates), and I should be able to perform arithmetic on elements. The AbstractAbelianGroup class should then have generic implementations of things like finding orders of elements, computing the exponent of the group, computing the structure of the group, which are then cached. (The reason I'm starting this thread at all is because I want to come up with a sane way to put these kind of generic group algorithms into SAGE.) Somehow at the moment in SAGE it's very difficult to separate the "group structure" from the "elliptic curve" structure. For example, suppose I have an elliptic curve over Q, and I want to work with points defined over some number field K/Q. Currently I think the only option I have is to base extend the curve to K, because points need to "belong" to the curve. But mathematically that shouldn't be necessary; I should be able to talk about K-valued points of a curve over Q. If I base-extend to K, I lose the information that the curve was really defined over Q (which might make certain computations easier). So what I would like to be able to do is call E.group_over_field(K) which returns an abstract abelian group. Maybe what I really want is a "ParentWithoutGens" base class :-) I'm really unsure of how to proceed with this. Especially since there are difficult coercion issues lurking in the background. Any thoughts would be most appreciated. david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: windows
On Nov 29, 2007, at 4:48 PM, mabshoff wrote: > > Ok, I started fleshing out the windows port page at > >http://wiki.sagemath.org/windows > > Please add content and/or comments, we need to get this going. A data > point: Maxima 5.13 was downloaded about 40,000 times for Windows since > the release in August while Linux downloads in that time frame are > less than 2,500. Maxima on Linux certainly has more distribution > channels like Linux distribution, but unless you live in Debian > unstable or some other very current distribution chances are you are > not running 5.13. Source downloads total about 4,000, so the binary > Windows download share is *huge* either way and we really need to get > on the Windows desktop. So, hypothetically speaking, if I wanted to help with windows development, what are my options for getting windows running on my macbook? david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: windows
On Nov 29, 2007, at 5:41 PM, mabshoff wrote: >> So, hypothetically speaking, if I wanted to help with windows >> development, what are my options for getting windows running on my >> macbook? >> > > With bootcamp you can install Windows in a separate partition. VMWare > Fusion lets you virtualize it (there is a free VMWare player, not sure > if it exists for Windows), Parallels is quite nice also, but also > costs some money. You need a windows license to install Windows > itself. So I would need to upgrade to 10.5.x ($$), and buy a copy of windows ($$), if I wanted to do this legally. That's quite a hurdle. > Another option is to use telnet and/or ssh to log into a Windows box > remotely. There are also various other protocols to access Windows on > a framebuffer level. It might be a good idea in the long term to set > up a box at U Washington to have a homogeneous development environment > and so on. If this can be done, that could be a great help. I do have access to my wife's windows machine, but it has a habit of freezing fairly regularly, and to be honest I don't enjoy using it very much. david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Raising matrices to a power
On Dec 3, 2007, at 8:40 AM, Bill Hart wrote: > I've just been looking at SAGE ticket number 173: > > http://www.sagemath.org:9002/sage_trac/ticket/173 > > The idea is that Mathematica raises a 3 dimensional matrix M over QQ > to the power 20,000 much faster than either SAGE or Magma. > > I don't know any algorithm for doing this efficiently. I only know one > algorithm: > > 1) Compute the characteristic polynomial p(x) of M (time 0.00s) > 2) Compute x^2 mod p (time 0.22s) > 3) Substitute M into the result (time 0.00s) > > It's pretty obvious where the time is going here - polynomial > arithmetic. I guess this is the algorithm being used. Is Pari or NTL > being used for the polynomial expmod? > > I reckon we can speed this up. What do people think? I would have guessed the algorithm was just "compute M^2 using repeated squaring". But your suggestion is quite interesting. Maybe first check that mathematica is getting the right answer, and not some stupid floating point approximation 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Raising matrices to a power
On Dec 3, 2007, at 11:20 AM, William Stein wrote: > > On Dec 3, 2007 8:13 AM, Bill Hart <[EMAIL PROTECTED]> wrote: >> I did try to check that Mathematica was getting the right answer, but >> I had no luck. I don't know how to convert a mathematica matrix into >> ordinary matrix form in SAGE, so when I do the comparison it always >> just says false. > > Damn it -- you're right. This isn't the first time I've been > bitten by > this. Mathematica is just doing the componentwise product! Ha ha ha ha ha. That would do it. We should have done that for polynomial multiplication too, that would be way faster. david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: [sage-support] Re: Weaning
On Dec 4, 2007, at 5:09 AM, fwc wrote:
>>> 1) Taylor series of a rational function.
>>
>>> This works:
>>> sage: cos(x).taylor(x,0,2)
>>
>>> This doesn't:
>>> sage: x/(1+x).taylor(x,0,2)
>>
>>> This is very confusing:
>
>> This is due to the fact that '.' binds tighter than '/'. For
>> example,
>> sage: x/(1+x).taylor(x,0,2)
>> x/(x + 1)
>> sage: x/((1+x).taylor(x,0,2))
>> x/(x + 1)
>> sage: (x/(1+x)).taylor(x,0,2)
>> x - x^2
>>
>> In Sage, "(x/(1+x))" creates an object and the you call the taylor()
>> method on that object.
>
> Mathematica has the advantage that Series creates a truncated series
> object rather than a polynomial. Thus it doesn't matter whether the
> division is done before or after:
>
> sage: mathematica("x/Series[1+x, {x, 0, 1}]")
> SeriesData[x, 0, {1, -1}, 1, 3, 1]
> sage: mathematica("Series[x/(1+x), {x, 0, 2}]")
> SeriesData[x, 0, {1, -1}, 1, 3, 1]
H this is an excellent point. We do have a PowerSeriesRing which
can keep track of where you truncated to, but it's only used in a
more strictly algebraic setting, it's not really part of the symbolic
calculus package. Is it possible for the symbolic calculus package to
do something similar to this? What about creating a PowerSeriesRing
with the SymbolicExpressionRing as the base ring?
sage: R. = PowerSeriesRing(SymbolicExpressionRing)
---
Traceback (most recent call
last)
/Users/david/ in ()
/Users/david/sage-2.8.14/local/lib/python2.5/site-packages/sage/rings/
power_series_ring.py in PowerSeriesRing(base_ring, name,
default_prec, names, sparse)
171 R = PowerSeriesRing_generic(base_ring, name,
default_prec, sparse=sparse)
172 else:
--> 173 raise TypeError, "base_ring must be a commutative ring"
174 _cache[key] = weakref.ref(R)
175 return R
: base_ring must be a commutative ring
Well maybe not
Would be nice though
david
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: soon everyday will be a Sage day
Yeah, I would be much more inclined to spend hours writing doctests if I knew there were like ten other people doing so at the same time. david On Dec 6, 2007, at 10:40 AM, Martin Albrecht wrote: > > Hi there, > > some quick idea such that Sage dominates our lives even more: > > 1. We should have "Doc Days" (*) in addition to "Bug Days". For > these sessions > we would focus on (a) finding new bugs by (b) writing doctests. > Also our Wiki > might need some care and the manuals always need updates. > > 2. Also, a "Busfactor/Code-Review Day" might be a good idea. There > are areas > in the Sage codebase where basically only one developer feels > comfortable > poking around. This is usually not because of scary math only one > person > cares about but because nobody else every sat down and read the > code. A "Bus > Day" (y'know what if that developer gets run-over by a bus) would > basically > mean that we sit down and read chunks of code by other developers. > If we are > stuck the authors are right there on IRC to discuss the random > questions we > come up with. The coercion model, libSingular and cremona.spkg are > examples > for this kind of code in my mind. This would also mean that we > review the > code which is a very very nice thing to have. > > (*) William just indicated on IRC that we should probably move away > from the > idea of a whole day to devote to bugs and stuff. Instead a Sage > Morning/Evening (depending on your favourite timezone) might allow > more > people to participate. E.g. weekends are usually a bad choice for me. > > Thoughts? > > Martin --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: quo_rem, __floordiv__, and polynomials
On Dec 7, 2007, at 10:45 AM, Nick Alexander wrote: > >> If the divisor is monic, then everything is okay, but if the divisor >> is not monic, it's not clear what the remainder should be. I took the >> agnostic option for the moment. > > Why not make it agree with Magma's multivariate definition (used in > their Euclidean ring Groebner basis calculations)? > > The reference is > > http://magma.maths.usyd.edu.au/magma/htmlhelp/text1115.htm#11136 > > I can elaborate. For what it's worth, I have implemented some of > this in a .sage file but I couldn't make it very general -- the > polynomial hierarchy is hard to comprehend these days. Ok but if you do this, you need to implement it by hand, since NTL (the underlying implementation for most of Polynomial_integer_dense) isn't able to do this, as far as I 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: quo_rem, __floordiv__, and polynomials
On Dec 7, 2007, at 8:48 AM, Joel B. Mohler wrote: > > Hi, > > Here's a couple of questions that have occurred to me as I tried to > make > fraction fields of mpolynomials tolerable to work with. > > 1) In the "reduce" method in the file fraction_field_element.py > (line 72), we > call quo_rem to divide the gcd out of the numerator and > denominator. Now, by > definition the remainder should be 0 so we throw out the > remainder. However, it > seems to me that it should be faster to give the base_ring the > information that > we don't care about the remainder by using the "//" operator (which > calls > __floordiv__). > > 2) Ok, so I think #1 is obviously correct and I tried it to see if > it made a > speed difference. It did, but the wrong way -- __floordiv__ is > slow for > polynomial_integer_dense_ntl.pyx and the docstring explains that we > don't know > how this is defined. I'm not sure what David Harvey's exact > questions are, but > I think we should get it figured out. An obvious fact that I'd > believe should > hold is that: > f.quo_rem(g)[0] == f//g > That seems to remove any ambiguity. I should mention that code is only several days old; it's the result of a bug-fix from the most recent bug days; it used to segfault on e.g. division by zero or division by a non-monic polynomial that didn't happen to be an exact divisor. If the divisor is monic, then everything is okay, but if the divisor is not monic, it's not clear what the remainder should be. I took the agnostic option for the moment. (BTW something that still needs to be fixed is that the code won't work if the leading coefficient is -1, which should 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Please review letter to Python GHOP
typos: On Dec 7, 2007, at 11:01 PM, Timothy Clemans wrote: > Magma. To achieve this goal in a reasonable about of time the Sage => "amount of time" > the direction of William Stein, lead developer of Sage, 24 talented > high school used Sage via the notebook in a computer lab to explore => "high school students" david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] since we all really love talking about licensing...
Hi guys, I am writing a library for polynomial arithmetic which I might eventually like to see included in Sage. (It is not presently part of FLINT, but maybe one day it will be.) I would like to release it simultaneously under GPL v2 and GPL v3. I specifically do not want to use the clause "either version 2 of the License, or (at your option) any later version." Basically I don't trust the FSF enough at the moment to release my code under GPL v7, so I want to stick with the existing licenses. Small portions of the source code of the library are adapted from existing software (NTL and FLINT), both of which are released under "version 2, or at your option any later version". It also includes some code from GMP 4.2.1, which is released under "LGPL v2.1, or at your option any later version". Two questions: Q1) Is it legal for me to do this? Am I violating the licenses of NTL, FLINT, or GMP? For example, since NTL is released under "version 2, or at your option any later version", am I violating Shoup's copyright by re-releasing part of his code under only v2 and v3? Q2) If I release under GPL v2 and v3 only, is it possible for Sage to use my code? thanks guys david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: trying to define acsc(x), acsch(x) and friends
On Dec 17, 2007, at 6:00 AM, Dan Drake wrote: > Hello, > > I'm trying to define inverse csc, sec, and cot and their hyperbolic > versions. I dug through > $SAGE_ROOT/devel/sage-main/build/sage/calculus/calculus.py and > thought I Hi Dan, I'm not sure if the following will solve your problem, but instead of editing files under $SAGE_ROOT/devel/sage-main/build/, you should edit the files under $SAGE_ROOT/devel/sage-main/sage/calculus/... and then run "sage -b" from $SAGE_ROOT before booting up sage 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] zn_poly -- request for testing
Hi folks, I've started working on a new C library called "zn_poly", which does polynomial arithmetic in (Z/nZ)[x], where n fits into an unsigned long. Similar to NTL's zz_pX class. This might eventually be part of FLINT, but for now it's a separate project. I am maintaining a website for zn_poly at http://math.harvard.edu/~dmharvey/zn_poly/ I have made an spkg for sage-2.9, you can get it from http://math.harvard.edu/~dmharvey/zn_poly/releases/zn_poly-0.4.1.spkg I don't know if this will build on all sage-supported systems yet. So far I have successfully built on: * sage.math (AMD opteron, debian linux) * bsd (a xeon I think?) * my laptop: core 2 duo, mac OS 10.4.10 * my desktop: ppc G5, mac OS 10.4.10 * my very old laptop: ppc G3, mac OS 10.3.9 (zn_poly, but not the spkg) I'd really appreciate people trying this out on various systems and reporting back what happens. As an application, I rewrote my "frobenius" program, which is currently included in Sage via sage.schemes.hyperelliptic_curves.frobenius.frobenius. This program computes the characteristic polynomial of frobenius (i.e. the zeta function) for a hyperelliptic curve over GF(p), where p is relatively large. Here is a patch which upgrades to the new version: http://sage.math.washington.edu/home/dmharvey/patches/hypellfrob.hg The algorithm depends heavily on polynomial arithmetic, often for a small (word-sized) modulus. The old version used NTL for the polynomial arithmetic (either ZZ_pX or zz_pX). The new version attempts to use zn_poly arithmetic where possible. Below are some example timings for the new version (on sage.math). It incorporates some algorithmic improvements too, but a lot of the speedup is due to zn_poly vs NTL. genus 2 (compute charpoly mod p) p = 2^16 + 1: old = 0.068s, new = 0.008s p = 2^20 + 7: old = 0.288s, new = 0.044s p = 2^24 + 43: old = 1.244s, new = 0.324s p = 2^28 + 3: old = 5.63s, new = 2.952s p = 2^32 + 15: old = 29.0s, new = 21.6s genus 3 (compute charpoly mod p) p = 2^16 + 1: old = 0.136s, new = 0.020s p = 2^20 + 7: old = 0.580s, new = 0.092s p = 2^24 + 43: old = 2.548s, new = 0.648s p = 2^28 + 3: old = 11.4s, new = 5.9s p = 2^32 + 15: old = 58.2s, new = 43.3s genus 4 (compute charpoly mod p^2) p = 2^16 + 1: old = 0.61s, new = 0.16s p = 2^20 + 7: old = 5.23s, new = 0.92s p = 2^24 + 43: old = 25.7s, new = 20.3s p = 2^28 + 3: old = 233s, new = 111s p = 2^32 + 15: old = 1246s, new = 1313s H that last one ain't so great. That's because zn_poly excels at small-to-medium polynomials, but isn't so good for large polynomials (yet!). david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: factoring benchmarks
On Dec 19, 2007, at 7:19 PM, Bill Hart wrote: > > I get about 7us per loop on sage.math for Pari for the exponentiation. > So perhaps this is all architecture dependent. This would not surprise > me in the slightest. > > At any rate, I suspect the algorithms used for factorisation are > implemented quite differently between NTL and Pari. Since both Pari > and NTL use GMP mpn's for underlying integer arithmetic in SAGE, I > think the algorithms being used for factorisation are much more > relevant than the speed of basic arithmetic, which should be the same > for both. > > The other point is that both Pari and NTL use finite field stuff to > factor polynomials over the integers. So the speed of integer > arithmetic is almost irrelevant. > > Having said all that, it is surprising that NTL is behind Pari for > polynomial factorisation, given the amount of work Victor put into > this. Can you try your example problems on sage.math? On the other hand, Shoup's research is mostly about the asymptotics for very large degree problems, so perhaps he didn't bother trying to optimise the small polynomial case very much (?) david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] #1426: new trac view: tickets ***reported by*** given user
Hi paul, is this what you wanted? http://sagetrac.org/sage_trac/report/9 david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: #1426: new trac view: tickets ***reported by*** given user
On Dec 20, 2007, at 8:47 PM, Robert Miller wrote: > David, > > Did you mean to attach something to that ticket? no... sorry I put "[with patch]" but I really meant "[solution has been implemented]" but no-one ever writes that and I didn't want to feel left out :-( The point is that there is a new "report" which allows you to easily see all the tickets you have reported, which is what paul apparently was asking for. david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: #1426: new trac view: tickets ***reported by*** given user
On Dec 20, 2007, at 8:52 PM, Yi Qiang wrote: > I believe it is supposed to be a custom view that shows tickets you've > reported, although it's not working for me. Are you logged in? (I don't suppose you're seeing tickets reported by ME? (i.e. by dmharvey?) Did I mess up?) david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: example of a Mathematica program from my lecture
On Dec 21, 2007, at 7:18 AM, mabshoff wrote: >> But please don't forget, sage is about open source - and windows is >> the complete opposite. > > [begin rant] Well, we support OSX, too, and that isn't exactly Open > Source either. While Apple itself is somewhat more friendly to the > Open Source idea than Microsoft on the software side you shouldn't [...] > I have been porting Software to and from Windows, OSX, Linux, Solaris, > HPUX and so on for many years now and in my experience those ports > always increase the quality of the code.[end rant] Wow, michael, that was the most awesome rant I've ever seen on sage- devel. I agree with you 150%. (well I reserve judgement on the women's track and field stuff, but let's not get into that.) My opinion is that having a native windows port is easily the single most effective way to boost Sage's user base. There are two problems. First is that a windows port is, as you point out, very, very (very, very) hard. Second problem, more important from an immediate practical point of view, is that the core of the sage developers don't know Windows, and don't have a convenient way to work with windows. You've seen at all the Sage Days workshops, it's like a macfest, with a couple of people running some kind of linux, and hardly anyone running windows. Moreover, most of us don't *want* to run windows. I've said it before and I'll say it again: if someone can make working on windows as easy and legal for me as "ssh sage.math", then I would probably be able to find some time to help out. If this can be made to happen then I think you will find more people interested in working on the port. david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: example of a Mathematica program from my lecture
On Dec 21, 2007, at 9:27 AM, Joel B. Mohler wrote: > > On Friday 21 December 2007 08:42, David Harvey wrote: >> I've said it before and I'll say it again: if someone can make >> working on windows as easy and legal for me as "ssh sage.math", then >> I would probably be able to find some time to help out. If this can >> be made to happen then I think you will find more people interested >> in working on the port. > > The irony is that both "easy" and "legal" are not so trivially > attainable with > *remote* use of windows. For instance, the cygwin ssh service on > windows [...] So you mean, the only way to do it is that someone buys some big license from Microsoft which allows multi-user remote access? Pricing is (number of users) * (price per license)? david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: example of a Mathematica program from my lecture
On Dec 21, 2007, at 10:16 AM, Joel B. Mohler wrote: >> So you mean, the only way to do it is that someone buys some big >> license from Microsoft which allows multi-user remote access? Pricing >> is (number of users) * (price per license)? > > That is my impression -- I don't know if the price per user can be > less than > price per license for local install. All of my past MS licensing > experience > has implied per user fees. Although some windows OS licenses are > per-computer, but there have always been (in my experience) clauses > closing > the loop-holes for lots of thin clients. Well damn. I guess this is the cost of doing development for Windows. So these are my options: (1) Use the windows lab on campus. Problem is, I believe for security reasons they wipe off the machines every day. I suppose I have some kind of permanent "home directory", but I'm not sure if I can install things like compilers into it. Also it's a colossal pain to lug myself over there, I don't know if I'd ever actually do it. (2) Use my wife's laptop. Not a good option: I don't want to mess with the OS at all, there's hardly any hard drive space left, the machine crashes regularly, and she needs it all the time. (3) Buy a windows license and use one of the virtualisation options mentioned before on this list to run it on my macbook. Not a good option: I'm too cheap. (4) I wonder if it's possible for the Sage foundation to set up a server and buy a small number of windows licenses for remote access. Say like 4 licenses, so only four people can be logged in at a time. Maybe that's a cost effective and legal way to do this. (Oh yeah, and then tell me I have to pay money for the client software too. Please say no.) david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] #1482: xgcd suboptimal output
Hi Nils, I've been looking at http://www.sagetrac.org/sage_trac/ticket/1482 and approximately diagnosed the problem (see comments on the ticket), but it's not clear to me exactly how to proceed. The new underlying gcd code produces quite inscrutable output, for example: sage: xgcd(3, 3) (3, 0, 1) sage: xgcd(3, 6) (3, -3, 2) sage: xgcd(3, 9) (3, -8, 3) sage: xgcd(3, 12) (3, -3, 1) sage: xgcd(3, 15) (3, -14, 3) sage: xgcd(3, 18) (3, -17, 3) sage: xgcd(3, 21) (3, -20, 3) sage: xgcd(3, 24) (3, -15, 2) sage: xgcd(3, 27) (3, -26, 3) sage: xgcd(3, 30) (3, -29, 3) sage: xgcd(3, 33) (3, -32, 3) sage: xgcd(3, 36) (3, -35, 3) sage: xgcd(3, 39) (3, -38, 3) sage: xgcd(3, 42) (3, -41, 3) sage: xgcd(3, 45) (3, -44, 3) sage: xgcd(3, 48) (3, -15, 1) sage: xgcd(3, 51) (3, -50, 3) It's very hard to see any rhyme or reason in that. Certainly the GMP documentation doesn't guarantee any properties of the cofactors, apart from bezout, either at the mpz or mpn levels, so it's not a bug. I'm inclined to do the following in Sage. Provide a "fast" flag which just calls GMP and doesn't provide any guarantees about the output (apart from satisfying bezout). If "fast" is False (default), then we convert to a "standard" form, which should be unique, mathematically sensible, and carefully documented. But having thought about it for a while, it's not even clear to me what exactly the right definition of "standard" should be. I don't quite understand the minimality condition you proposed. Apart from the kind of special case listed above, GMP does seem to follow some "rules", but I'm not sure they are always satisfied, and we can't rely on them since the GMP documentation doesn't promise anything. For example, if 0 < a < b, then xgcd(a, b)[1] always seems to be negative and xgcd(a, b)[2] always positive, but it swaps around if 0 < b < a: sage: xgcd(11, 17) (1, -3, 2) sage: xgcd(17, 11) (1, 2, -3) i.e. it looks like it swaps them to make a < b, and then swaps the cofactors at the end. It generally seems to handle input signs in the same way, i.e. it first does xgcd(|a|, |b|), then throws the signs back in at the end: sage: xgcd(11, 17) (1, -3, 2) sage: xgcd(-11, 17) (1, 3, 2) sage: xgcd(11, -17) (1, -3, -2) sage: xgcd(-11, -17) (1, 3, -2) But none of this is particularly canonical. What's the "right" way to do this? david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: SAGE-2.9.1
When I upgrade from 2.9 to 2.9.1, the FLINT test suite is being run. Probably it's a good idea to disable this in the release versions, it's quite time-consuming? Also I noticed this during the test suite (mac os 10.4.10, ppc g5): [...] Testing fmpz_convert()... ok Testing fmpz_size()... ok Testing fmpz_bits()... ok Testing fmpz_sgn()... ok Testing fmpz_set_si()... ./spkg-check: line 50: 25204 Abort trap ./fmpz-test Testing fmpz_poly_tofromstring()... ok [...] ?? david On Dec 24, 2007, at 1:50 PM, William Stein wrote: > > Hi, > > SAGE-2.9.1 has been released. > > See > http://sagemath.org/announce/sage-2.9.1.txt > for the release notes (which I've copied below). > > Download the source code from: > http://sagemath.org/dist/src/i > > Binaries will be available in a day or two. > > William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: SAGE-2.9.1
On Dec 24, 2007, at 7:40 PM, Bill Hart wrote: > > I did find some occurrences of 63 instead of FLINT_BITS-1, but I don't > believe this should be causing any problems with that function. > > Since the function doesn't say fail, I can only imagine this is an out > of memory problem. But I don't see any leaks, nor any requests for > large blocks. > > Can you tell me what happens when you run fmpz-test on its own on the > G5. A global search and replace of 63 with FLINT_BITS-1 will fix the > abovementioned. I changed the 63 to 31 in test_fmpz_set_si, and now it seems to work (and subsequently fails on the test_fmpz_set_ui test, presumably for the same reason). Kind of surprising that the test was passing on all those 32-bit machines out there. Note that the G5 is a 64-bit machine, but in sage everything only compiles in 32-bit mode. david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] sagemath.org metadata
When you google for "mathematica", at the top of the search results
you get this a bunch of extra links ("Students", "Mathematica Home
Page", "Demonstrations Project", etc.)
I'm not sure how this works, I guess it's some meta-data in the html
of the mathematica website. I'm sure someone on this list knows how
this works.
Now that Sage is #1 on google, it would be good to have some of our
links like this. At the very least, we should have a "notebook" link,
a "download" link, and a "tutorial" link.
david
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: SCREMS proposal
Here are some random things, nothing terribly important. project_summary.pdf: * "Kazhdan-Lusztig-Vogan" should use en-dashes not hyphens (this occurs in a few other files too I think, also Sato-Tate, etc. (but not Swinnerton-Dyer!)) * "Much of the data that arises out of these projects will also be of great value to large parts of mathematics." Perhaps of great value to mathematicians, rather than mathematics per se? * It's a bit puzzling the way Sage is introduced on that page. Maybe it's okay given some context I don't know about, but it looks a bit odd there without further explanation. project_description.pdf: * Ghz => GHz (this occurs a few times) * after "possibilities", should be an em-dash. * the headings in section 2.1.1 are aligned funny. "Further KLV computations" has different indentation from the following headings. * jordan-holder, I *think* holder has an umlaut, although the internet doesn't totally agree with me * Is it "Wiles'" or "Wiles's"? I'm not sure, but you use both :-) * p9: write "for example" not "e.g." * "Q curve" or "Q-curve"? Pick one and stick with it. * there's a funny space between "doubly even" and the comma * p12: probably better to write "with respect to" instead of "w.r.t" * the phrase "High amounts of symmetry" sounds not-quite-right to me, but I can't think of a better way. * "Google source code system.", -- the punctuation here is wrong. I think it should be "Google source code system," said ... Stein bio: * 284 page => 284 pages * the paper on computation of p-adic heights is not "to appear", it has well and truly appeared, but you knew that :-) Tired. Must sleep. david On Jan 10, 2008, at 8:47 PM, William Stein wrote: > > Hi, > > The Screms proposal is now completely done, but it's possible for me > to make some last minute minor > typo fixes tomorrow morning. I've posted the latest version here: > http://wstein.org/grants/screms/ > > If you notice _any_ typos or mistakes at all, definitely let me know. > The proposal is supposed > to be perfect right now. > > -- william > > -- > William Stein > Associate Professor of Mathematics > University of Washington > http://wstein.org > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 2.10.alpha2 released
Build successful on mac OS 10.4.10, ppc G5. Didn't run doctests due to known issue with combinatorics stuff. david On Jan 11, 2008, at 3:24 PM, mabshoff wrote: > > Hi, > > Sage 10.2.alpha2 is out. The main change is the switch > of python to ucs4. If you don't know what that is don't > worry about it. It turned out to be much less painful > than I anticipated, but I only build and doctested on > Linux x86-64 and OSX 10.5, so the problems might still > come out of the woodwork. Otherwise we made some > progress, but the main package merge is still ahead for > us. The ucs4 ticket as well as mhansen's combinat update > still remain open in trac. If anybody would like to take > a closer look at #1685 plese do so. > > Tarball [198MB] is at > > http://sage.math.washington.edu/home/mabshoff/release-cycles-2.10/ > sage-2.10.alpha2.tar > > Cheers, > > Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: [sage-support] Re: associativity of addition on ell. curves
(moved over from sage-support...) On Jan 14, 2008, at 10:28 PM, David Harvey wrote: > What would be *really* nice is if we could work directly in the > fraction field of the quotient of R. by the > appropriate ideal. (Does that even make sense? Is the ideal prime?) I > tried to do this but Sage gave up pretty quickly on me. A nice encore > would be to do this using Sage's elliptic curve class to do the > actual arithmetic. After all EllipticCurves can be defined over any > field > > Here's my dream session: > > sage: R. = QQ[] > sage: I = R.ideal(y1^2 - x1^3 - a*x1 - b, y2^2 - x2^3 - a*x2 - b, > y3^2 - x3^3 - a*x3 - b) > sage: S = FractionField(R.quotient(I)) # currently barfs > sage: E = EllipticCurve(S, [a, b]) > sage: P1 = E(x1, y1) > sage: P2 = E(x2, y2) > sage: P3 = E(x3, y3) > sage: (P1 + P2) + P3 == P1 + (P2 + P3) > True Ha ha ha I can almost make this work. I edited sage/rings/ideal.py so that is_prime() always returns True and is_maximal() function always returns False (not a good long-term solution.) Then: sage: R. = QQ[] sage: I = R.ideal(y1^2 - x1^3 - a*x1 - b, y2^2 - x2^3 - a*x2 - b, y3^2 - x3^3 - a*x3 - b) sage: S = FractionField(R.quotient(I)) sage: S Fraction Field of Quotient of Multivariate Polynomial Ring in x1, y1, x2, y2, x3, y3, a, b over Rational Field by the ideal (-x1^3 + y1^2 - x1*a - b, -x2^3 + y2^2 - x2*a - b, -x3^3 + y3^2 - x3*a - b) sage: E = EllipticCurve(S, [a, b]) sage: E Elliptic Curve defined by y^2 = x^3 + abar*x + bbar over Fraction Field of Quotient of Multivariate Polynomial Ring in x1, y1, x2, y2, x3, y3, a, b over Rational Field by the ideal (-x1^3 + y1^2 - x1*a - b, -x2^3 + y2^2 - x2*a - b, -x3^3 + y3^2 - x3*a - b) sage: P1 = E(x1, y1) sage: P1 (x1bar : y1bar : 1) sage: P2 = E(x2, y2) sage: P3 = E(x3, y3) sage: P1 + P2 ((x1bar^2*x2bar + x1bar*x2bar^2 - 2*y1bar*y2bar + x1bar*abar + x2bar*abar + 2*bbar)/(x1bar^2 - 2*x1bar*x2bar + x2bar^2) : (-3*y1bar^3*x2bar^2 + x1bar^2*y1bar^2*y2bar + x1bar*y1bar^2*x2bar*y2bar - 5*y1bar^2*x2bar^2*y2bar + 5*x1bar^2*y1bar*y2bar^2 - x1bar*y1bar*x2bar*y2bar^2 - y1bar*x2bar^2*y2bar^2 + 3*x1bar^2*y2bar^3 - 6*x1bar^2*y1bar*x2bar*abar + 9*x1bar*y1bar*x2bar^2*abar - 9*x1bar^2*x2bar*y2bar*abar + 6*x1bar*x2bar^2*y2bar*abar - y1bar^3*abar + 2*y1bar^2*y2bar*abar - 2*y1bar*y2bar^2*abar + y2bar^3*abar + x1bar*y1bar*abar^2 + 2*y1bar*x2bar*abar^2 - 2*x1bar*y2bar*abar^2 - x2bar*y2bar*abar^2 - 9*x1bar^2*y1bar*bbar + 9*x1bar*y1bar*x2bar*bbar - 9*x1bar*x2bar*y2bar*bbar + 9*x2bar^2*y2bar*bbar + 3*y1bar*abar*bbar - 3*y2bar*abar*bbar)/ (x1bar^2*y1bar^2 - 5*x1bar*y1bar^2*x2bar + 10*y1bar^2*x2bar^2 - 10*x1bar^2*y2bar^2 + 5*x1bar*x2bar*y2bar^2 - x2bar^2*y2bar^2 + 15*x1bar^2*x2bar*abar - 15*x1bar*x2bar^2*abar - y1bar^2*abar + y2bar^2*abar + x1bar*abar^2 - x2bar*abar^2 + 9*x1bar^2*bbar - 9*x2bar^2*bbar) : 1) sage: Q1 = (P1 + P2) + P3 but then it chickens out. Sage thinks for about 90s, chews up 400MB RAM, then singular takes over and just sits there for a while. Maybe it's doing a multivariate gcd somewhere? Dunno. Funny thing is that singular doesn't use much memory at all. I killed it after 10 minutes. Any ideas? david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: [sage-support] Re: associativity of addition on ell. curves
On Jan 15, 2008, at 4:08 AM, John Cremona wrote:
> I think this computation (in the quotient ring) makes sense even if
> the ideal is not prime. I had already tried to do it that way, but
> failed.
>
> However I am not quite convinced that verifying P1+(P1+P3)==(P1+P2)+P3
> is genuinely proving anything! Since in the implementation of
> elliptic curve addition, it may well be that commutativity and/or
> associativity are implicitly assumed.
Ah yes. I agree this is a problem for verifying commutativity. For
associativity, what if you did the following. First compute P1 + P2
in generic coordinates using the EllipticCurve class, i.e. you get
the coordinates of P1 + P2 as a function of x1, y1, x2, y2 in the
appropriate quotient ring. Then introduce x3, y3, relabel variables,
and make the appropriate substitutions to verify that the "formula"
for the coordinates of (P1 + P2) + P3 is the same as the formula for
P1 + (P2 + P3). Would this constitute a correct verification of
associativity (perhaps modulo problems caused by the point at infinity)?
> I tried doing this in Magma some time ago, using something like David
> Harvey's code. I longed for a function GenericPoint() for a curve, so
> that for example
> (x1,y1)=E.GenericPoint()
> would return a point where x1,y1 live in the function field k(x1,y1)
> of the curve. In fact I did manage to do that in Magma, but had
> problems then trying to define a second *independednt* generic point,
> since in Magma there is only ever *one* univariate polynomial ring
> over any given field. To get a second generic point I had to make a
> base change of the curve from k (the proginal ground field) to the
> function field k(x1,y1), and then define a second point (x2,y2) such
> that k(x1,y1){x2,y2) is the function field of the curve over k(x1,y1).
> I think I was then able to verify commutativitybut chickened out
> before going up another level to get a third point.
>
> There may be a better way of doing all that in Magma than I was doing,
> and I'm not sure that I care now. But I think it would be really
> useful if in Sage we could define a GenericPoint for a curve, in such
> a way that subsequent calls to it returned independent generic points.
> Does anyone think that might be possible?
That would be very nice.
The problem is once you've called (x1, y1) = E.generic_point()
and (x2, y2) = E.generic_point(), suppose Sage was able to construct
two different function fields (which I think it can). When you try to
add the points, at some stage it has to decide what field (or ring)
the sum is defined over, since it has to be a point on *some*
elliptic curve. But that should never work, for the same reason that
this can't work:
sage: R. = ZZ[]
sage: S. = ZZ[]
sage: x + y
[boom]
I can't remember exactly all the things that are supposed to be wrong
with the above example, but I remember discussing this ad nauseum
with a few people at various Sage Days (what's the plural of Sage
Days?), and we definitely agreed it would be bad for this to work. I
think perhaps the problem is that perhaps there are relations between
x and y, and Sage has no way of knowing that without you explicitly
telling it. I don't think this was the whole story though. Perhaps
someone else remembers.
BUT I think it would be totally reasonable to support a syntax more like
E2, P = E.generic_point()
which returns a new elliptic curve over the function field (as you
suggested), and a point P = (x, y) on that curve, and then you could
subsequently do
E3, Q = E2.generic_point()
to get another point. But then you have the problem that adding
points in different orders give you fields that Sage would almost
certainly not recognise as being the same field. In fact it
*shouldn't*, for exactly the same reason that x + y doesn't work in
the above example, so I don't think this solves anything.
Hmmm.. the more I think about it, the more this is exactly like
the example I suggested above. Perhaps the analogy is clearer if I
write:
sage: E1. = E[]
sage: E2. = E[]
sage: P + Q
david
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: [sage-support] Re: associativity of addition on ell. curves
On Jan 15, 2008, at 4:54 PM, Robert Bradshaw wrote:
> What about
>
> sage: K. = NumberField(x^2 + x - (3^3-3))
> sage: E = EllipticCurve('37a'); E
> Elliptic Curve defined by y^2 + y = x^3 - x over Rational Field
> sage: X = E.change_ring(K); X
> Elliptic Curve defined by y^2 + y = x^3 + (-1)*x over Number Field in
> a with defining polynomial x^2 + x - 24
But I think John wants the curve to be still defined over the base
field. If E/K is an elliptic curve, and L/K is a field extension, and
P is in E(L), then you lose information if you base change the curve
up to E/L and think of P as a point on E/L. For example P doesn't
have any non-trivial galois conjugates any more. To retain these you
need to "remember" that the curve is actually defined over K.
david
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] infinity
Hi folks (especially william + robert + david roe), I showed up for Doc Days 1 and started looking at the infinity and extended integer ring stuff. Question: why does the "unsigned infinity ring" not have a zero element, whereas the "(signed) infinity ring" has a zero? This is okay: sage: 0 / Infinity Zero But this is way confusing: sage: oo = UnsignedInfinityRing(Infinity) sage: 0 / oo A number less than infinity I totally expected the last output to be Zero. But it can't be, because the UnsignedInfinityRing doesn't have a zero element. On the other hand, if there's a zero element, then you start having issues with things like sage: UnsignedInfinityRing(2) - UnsignedInfinityRing(3) because you can't tell if it's zero or not. Thoughts? david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sage features/bugs
On Jan 18, 2008, at 11:32 AM, William Stein wrote: >> Let A be a matrix not over ZZ or QQ: >> >> A.adjoint() >> A.inverse() >> >> are not implemented. > > I don't think they should be. There are already (at least) 3 ways > to do this: Wait a sec I agree with David K on the adjoint issue. The adjoint doesn't require the fraction field to even be constructed, and it makes perfect sense over non-domains. > sage: A = random_matrix(ZZ,2) > sage: ~A > > [ 1/34 1/17] > [-6/17 5/17] > sage: A.__invert__() > > [ 1/34 1/17] > [-6/17 5/17] > sage: A^(-1) > > [ 1/34 1/17] > [-6/17 5/17] I vaguely recall being stung several times by the lack of an inverse () method. For someone who doesn't know python that well, neither ~ nor __invert__ are obvious alternatives. I don't think it would hurt at all to have an inverse() method. >> For x a commutative ring element: >> >> x.inverse() >> >> is not implemented even if x^-1 exists. > > Same remark as above. > >> sage: x = 7 >> sage: type(x) >> >> sage: x^-1 >> 1/7 >> sage: type(x^-1) >> >> sage: x = -1 >> sage: type(x^-1) >> >> Should the field of fractions be created? Oooh these are hard. We still haven't settled on consistent semantics for the power operator. Given the types of A and B, I'm never sure what to expect the type of A^B to be. For example: sage: type(Integer(2)^Rational(2)) sage: type(Integer(2)^Rational(1/2)) That really bothers me. >> Certaily x.inverse() should return an error for non-units. > > No it shouldn't. It should compute the inverse as an element of a > natural > larger structure. Huh? How do you do this? What's the inverse of 2 mod 6? What is the larger structure? If anything it's the localisation, but that's not "larger". 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 features/bugs
On Jan 18, 2008, at 12:46 PM, William Stein wrote: >> Oooh these are hard. We still haven't settled on consistent semantics >> for the power operator. Given the types of A and B, I'm never sure >> what to expect the type of A^B to be. For example: >> >> sage: type(Integer(2)^Rational(2)) >> >> >> sage: type(Integer(2)^Rational(1/2)) >> >> >> That really bothers me. > > Why do you think the type of an expression should be trivial to > determine from the inputs to the expression? This would be nice, > but it really makes no sense to expect in something as complicated > as a computer algebra system. Of course, we could make it so > a^b has either the type of a, the type of b, or raises an error. > That's > how it used to be. But then so many things don't work, or become much > harder, or frustrating if you actually want to _use_ Sage. I think we should try to make the types easy to figure out as often as we can. For example, the fact that "5/1" gives you a rational instead of an integer is I think a Good Thing. It means that it's easier to write code that uses the / operator, the system is more predictable. But I agree ^ is much more complicated, and I can't see how to do it. Certaily x.inverse() should return an error for non-units. >>> >>> No it shouldn't. It should compute the inverse as an element of a >>> natural >>> larger structure. >> >> Huh? How do you do this? What's the inverse of 2 mod 6? What is the >> larger structure? If anything it's the localisation, but that's not >> "larger". > > An error. You only do this when it makes sense. E.g., if A is a > matrix > with integer entries, there is a reasonably natural place in which to > compute the inverse of A, namely matrices over the rationals. To say, > "sorry you can't do that", will just make Sage that much harder to > use. > Inverting 2 mod 6 is completely different, since there is no standard > agreed upon meaning, since there is no ring that contains Z/6Z in > which > 2 is invertible. Sounds fine. 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: more on number of digits
On Jan 27, 2008, at 10:44 PM, Alex Ghitza wrote: > David's suggestion was: > - - > * instead of computing the whole power, just estimate the top > couple of > digits using MPFR (much much much faster than computing the whole > power) > * keep increasing precision until we can distinguish the input > from the > power. > > Maybe this would be easiest to implement using interval arithmetic. > > The point is, for uniform random input, the top couple of digits will > almost always give you the right answer straightaway. It's very > rare that > you need to compute everything. I wish I had more time to think about > this, it sounds like a fun problem. > - - > > We actually know what the first few digits (or, actually, all of them) > of *compare* are: 1000... Sorry, you're right, I wasn't very coherent. What I think I meant was to quickly compute the top few *binary* digits of "compare". The reason for this is that everything is stored internally in binary, so it's very easy to read off the top few *binary* digits of "self". 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: more on number of digits
On Jan 27, 2008, at 10:55 PM, David Harvey wrote: >> We actually know what the first few digits (or, actually, all of >> them) >> of *compare* are: 1000... > > Sorry, you're right, I wasn't very coherent. > > What I think I meant was to quickly compute the top few *binary* > digits of "compare". The reason for this is that everything is stored > internally in binary, so it's very easy to read off the top few > *binary* digits of "self". BTW I think the following might be relevant: sage: I = RealInterval(10.0, 10.0) sage: I [10.000 .. 10.000] sage: I**1 [9.3908e .. 1.0429e1] I don't know exactly what this means, since I don't understand enough about the semantics of the constructor, but surely someone like Carl Witty would know. (and is this is a bug: sage: I**10 [2.0985787164673874e323228496 .. +infinity] ???) 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: more on number of digits
On Jan 28, 2008, at 6:47 PM, Alex Ghitza wrote: > OK, I'm quite happy with this (thanks David for suggesting it > and Carl for telling me how to do it!) > > I've put this in and played around with it. It is definitely > *much* faster for the huge examples that I tried, and it's > also fast enough on smaller numbers. > > I'll post a new patch for #1014 shortly. David, is it ok if I > replace the current exact_log() function with > > return self.ndigits(m) - 1 > > (after checking self is positive, etc.)? That would be okay, as long as you address the issue Carl brings up in a subsequent email regarding the maximum base being 256; exact_log is used in a few places in the p-adics code, where we might encounter a larger base. Unfortunately I don't think there are any doctests yet to cover the large base case. To be honest, my preference would be to put the guts of the implementation in exact_log, and get ndigits to call exact_log. My feeling is that "logarithm" is closer to the real mathematical meaning we're after, and "number of digits" is an application. But this is open to debate. 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] problem with test framework
I'm having a weird problem, I think with the test framework. I have a clean build of 2.10.1, and clone a new branch. In this branch, I can do ./sage -t devel/sage/sage/rings/arith.py, and all tests pass. Now I edit that file arith.py. At line 874, I change sage: random_prime(10) 54601 to sage: p = random_prime(10); p 54601 Then I do sage -b, and the same sage -t command again. Now I get: sage -t devel/sage-2128/sage/rings/arith.py ** File "arith.py", line 874: sage: _= p = random_prime(10); p Expected nothing Got: 22073 ** 1 items had failures: 1 of 2 in __main__.example_19 ***Test Failed*** 1 failures. For whitespace errors, see the file .doctest_arith.py [5.2 s] exit code: 256 What is going on here? (I ran into this while trying to write a patch for http:// sagetrac.org/sage_trac/ticket/2128) This is an intel macbook, OS 10.4.11. 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: problem with test framework
On Feb 10, 2008, at 9:13 PM, William Stein wrote: > Any line with "random" anywhere in it is replaced by > >sage: _ = [the original line] > >[original output] <--- gets ignored because of the newline > > This is so doctests with random output can still be run using exactly > the same doctesting framework, but the output is not tested. > > This is a hack, clearly. It would be better to run the random input > line *exactly* as is, but just somehow ignore the output. When I > wrote [...] okay I see. A much better solution would be for sage to have a sane pseudo-random number framework, so we could be guaranteed sane behaviour for doctests like this. I realise how difficult this is, given how many systems there are in sage with different random number generators etc. Actually this burns me quite often for various reasons. I frequently have some code that I'm playing with, and I'm debugging deep into some complicated piece of code, and I have a piece of paper with various numbers written on it keeping track of what's supposed to be happening and then I run it again and I get totally different numbers and I have to work it all out again. It's a real pain, and quite unworkable. BTW this is a hack for two reasons. The "lesser hack" is that it rewrites code that is supposed to have random output. I suppose I can live with this. But the "greater hack", which is much more confusing to me, is that it gets applied for any line containing the string "random"!! That's totally unexpected and weird. i.e. I could live with: sage: some_func(5) # random 234736 where it's clearer that there is some decoration on the line. What about sage: rand_stuff() or sage: rnd_stuff() ? 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: cyclotomic_polynomial should be over ZZ?
On Feb 12, 2008, at 8:32 PM, Nick Alexander wrote: > Do others agree that cyclotomic_polynomial should be over ZZ? If so, > I will fix it. Absolutely. 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: discrete logs
On Feb 13, 2008, at 5:09 PM, Nick Alexander wrote: > John also needs identity and inverses, which requires passing in > three or functions. Or, more likely a struct, which in an OO > language, I call an object. > > To me, that means you're writing a special purpose "abstract group" > wrapper for discrete logs, which is fine. But I believe the heavier This would be great to have in sage. I wanted to work on something like this in collaboration with Andrew Sutherland a few months back, but that whole annoying thesis thing got in the way. Our idea was to have the underlying abstract group algorithms (like computing discrete logs, exponents of groups, orders of groups, group structures etc) written in C++ with templates. Andrew has had a lot of experience with this. One instantiation would be a black box using C function pointers, which we could then plug into a cython class to perform the arithmetic. 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: problem with test framework
On Feb 14, 2008, at 1:21 AM, Robert Bradshaw wrote: >> I'm still willing to work on the "randgen" class I described toward >> the end of this thread: >> http://groups.google.com/group/sage-devel/browse_thread/thread/ >> c2d86a2685018112/4b3136c4a784015a?#4b3136c4a784015a >> >> Basically I'm just waiting for somebody to say "Yes, that looks >> like a >> good design" before I start. > > I would really like to see a sane, centralized pseudo-random number > framework. Requiring every function that uses (perhaps implicitly) > random numbers to pass around optional randgen objects will, in my > opinion, be both inefficient and cumbersome to program with. Rather, > I think the best option is to have a global randgen object that holds > states for the various frameworks we use (e.g. gmp, ntl, etc.) where > algorithms can access it directly. Swapping out this generator for a > new one should be handled via python contexts. Hmmm. I like this idea in principle, but can it really be made to work? How many underlying systems are we talking about here? Also, what about the following issue. I just looked at the NTL random number framework. There doesn't seem to be any (supported) interface for getting/setting state. The best you can do is: void SetSeed(const ZZ& s); s itself is hashed before being used. So without going into internals, I don't see how you can restore a previous state. (well I suppose you could just call SetSeed again and count the number of previous calls you made to Random() :-)) 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: cached data in a class instance
On Feb 21, 2008, at 1:18 PM, John Cremona wrote: > > Can someone point me to the documentation for the feature where, > for example, > > E.__order > > is translated to > > E._EllipticCurve_finite_field__order ? > > It appears that in several places where I thought I was caching data, > I am not successfully retrieving it, with some serious performance > consequences in the (accepted) patch for trac #1130 on elliptic curves > over finite fields. > > Basically I need to know when to use the short form and when the > long. I think. This is a feature of python that I don't completely understand, but at least some documentation is here: http://docs.python.org/ref/atom-identifiers.html 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 2.10.2.rc0 release!
On Feb 21, 2008, at 10:15 PM, mabshoff wrote: > > Hello folks, > > this is 2.10.2.rc0, which hopefully will be identical to 2.10.2 > final. > Please build and doctest this release and report any issue you > come across. At this point only critical issues will be patched, > i.e. doctest failures or segfaults. Everything else will have > another chance in 2.10.3. GNUTLS build failed, core 2 duo, mac OS 10.4.11, MAKE=make -j2. Here's the end of the log: [.] ../lib/.libs/libgnutls.dylib(md2.o) definition of _md2_process_block ld: warning multiple definitions of symbol _md2_read_ctx .libs/libgnutls-openssl.lax/liblgnu.a/md2.o definition of _md2_read_ctx in section (__TEXT,__text) ../lib/.libs/libgnutls.dylib(md2.o) definition of _md2_read_ctx ld: warning multiple definitions of symbol _md2_stream .libs/libgnutls-openssl.lax/liblgnu.a/md2.o definition of _md2_stream in section (__TEXT,__text) ../lib/.libs/libgnutls.dylib(md2.o) definition of _md2_stream (cd .libs && rm -f libgnutls-openssl.26.dylib && ln -s libgnutls- openssl.26.1.2.dylib libgnutls-openssl.26.dylib) (cd .libs && rm -f libgnutls-openssl.dylib && ln -s libgnutls-openssl. 26.1.2.dylib libgnutls-openssl.dylib) rm -fr .libs/libgnutls-openssl.lax creating libgnutls-openssl.la (cd .libs && rm -f libgnutls-openssl.la && ln -s ../libgnutls- openssl.la libgnutls-openssl.la) make[4]: *** [all-recursive] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 failed to build GNUTLS real1m54.769s user0m53.751s sys 1m20.593s sage: An error occurred while installing gnutls-2.2.1.p1 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 2.10.2.rc0 release!
On Feb 22, 2008, at 8:29 AM, Michael.Abshoff wrote: > Could you please post slightly more of the log? It looks like it > happens > during "make install" which would make it easy to fix. Is it > reproducible? http://sage.math.washington.edu/home/dmharvey/install.log.gz I am going to try building again now with -j1. 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 2.10.2.rc0 release!
On Feb 22, 2008, at 2:43 PM, mabshoff wrote: > Hi David, > > I poked around in the install log and the issue is "Resource > temporarily unavailable", i.e. the dreaded OSX resource limits that > are too low. A suggested fix is at > > http://wiki.sagemath.org/Tips Thanks, well spotted! > So: no bug in Sage here, nothing to see, go along ;) I believe the correct idiom is "nothing to see here, move along". > It would be nice if the two issues from Tips would be moved to the > FAQ. I'm not sure exactly what to write about the other Tip in the FAQ, but I'll move the resource limit one there now. 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: exact cover problem
On Feb 22, 2008, at 3:49 PM, William Stein wrote: > > On Fri, Feb 22, 2008 at 12:04 PM, Jason Grout > <[EMAIL PROTECTED]> wrote: >> >> [EMAIL PROTECTED] wrote: >>> I've found a nice implementation of the DLX algorithm, which >>> "quickly" solves the NP-Complete exact cover problem. For those >>> who aren't in Seattle and haven't heard me blathering on and on >>> and on and on about how awesome DLX is... >>> >>> Let M be a binary matrix. An exact cover is a subset of the rows >>> of the matrix who sum (exactly) to the vector 1,1,...,1. >>> > > Isn't that exactly the same thing as solving > >M*x = [1,...,1], > > over GF(2)? I think it's probably not mod 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: some more entries for sagemath.org/pub.html
On Feb 23, 2008, at 10:33 AM, Alex Ghitza wrote: > David Harvey, http://arxiv.org/abs/0708.3404";>Efficient > computation of p-adic heights (18 pages), 2007. This will appear soon in LMS JCM. http://www.lms.ac.uk/jcm/ > David Harvey, http://arxiv.org/abs/math/0610973";>Kedlaya's > algorithm in larger characteristic (21 pages), 2006. This was published in IMRN: http://imrn.oxfordjournals.org/cgi/content/abstract/2007/rnm095/rnm095 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
On Feb 23, 2008, at 1:03 PM, Carl Witty wrote: > Currently, symbolic expressions have 3 identical "derivative" > methods: .derivative(), .diff(), and .differentiate() (that is, they > are aliases of each other). These have a powerful argument list; > foo.diff(x, 3, y, z, 2) differentiates three times with respect to x, > then once with respect to y, then twice with respect to z. (And if > foo contains only one variable, then foo.diff() differentiates with > respect to that variable.) > > Polynomials (both univariate and multivariate) have a .diff() method, > which takes a required variable argument; univariate polynomials also > have a .derivative() method, which does not take an argument. > > There are also global functions diff(), differentiate(), and > derivative(), which are basically wrappers for the .derivative() > method: diff(foo, ...) is equivalient to foo.derivative(...). > > 1) Do we really need three names for this concept? Could we get rid > of one or two? If so, can we just remove it, or do we need some sort > of deprecation procedure? > > 2) I plan to make the polynomial methods match the symbolic expression > methods. (This should be backward-compatible.) Any objections? Carl, I'm glad you've brought this up now, I was planning to take this on myself in the next few days. I strongly agree everything should be harmonised. Here are several related tickets: http://trac.sagemath.org/sage_trac/ticket/756 http://trac.sagemath.org/sage_trac/ticket/753 http://trac.sagemath.org/sage_trac/ticket/1578 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
okay I made a list of all diff() and derivative() and differentiate() functions that we should probably be caring about for this issue. The list does not include aliases. functions/elementary.py class ElementaryFunction_class(CommutativeRingElement): def differentiate(self,verbose=None): interfaces/maxima.py class MaximaElement(ExpectElement): def diff(self, var='x', n=1): calculus/calculus.py class SymbolicExpression(RingElement): def derivative(self, *args): class Symbolic_object(SymbolicExpression): #def derivative(self, *args): calculus/functional.py def derivative(f, *args, **kwds): functions/piecewise.py class PiecewisePolynomial: def derivative(self): rings/polynomial/polynomial_modn_dense_ntl.pyx cdef class Polynomial_dense_mod_n(Polynomial): def diff(self, variable, have_ring=False): rings/polynomial/multi_polynomial_libsingular.pyx cdef class MPolynomial_libsingular (sage.rings.polynomial.multi_polynomial.MPolynomial): def diff(self, MPolynomial_libsingular variable, have_ring=True): rings/polynomial/polynomial_singular_interface.py class Polynomial_singular_repr: def diff(self, variable, have_ring=False): misc/functional.py def derivative(x): rings/laurent_series_ring_element.pyx cdef class LaurentSeries(AlgebraElement): def derivative(self): rings/polynomial/polynomial_element.pyx cdef class Polynomial(CommutativeAlgebraElement): def derivative(self): rings/polynomial/polynomial_element_generic.py class Polynomial_generic_sparse(Polynomial): def derivative(self): rings/polynomial/polynomial_modn_dense_ntl.pyx cdef class Polynomial_dense_mod_n(Polynomial): def derivative(self): cdef class Polynomial_dense_modn_ntl_zz(Polynomial_dense_mod_n): def derivative(self): rings/power_series_poly.pyx cdef class PowerSeries_poly(PowerSeries): def derivative(self): rings/power_series_ring_element.pyx cdef class PowerSeries(AlgebraElement): def derivative(self): rings/sparse_poly.pyx cdef class Polynomial: def derivative(self): There's also stuff in the following files which we probably shouldn't worry about: libs/ntl/ntl_GF2X.pyx libs/ntl/ntl_lzz_pX.pyx libs/ntl/ntl_ZZ_pEX.pyx libs/ntl/ntl_ZZ_pX.pyx libs/ntl/ntl_ZZX.pyx schemes/elliptic_curves/monsky_washnitzer.py lfunctions/dokchitser.py 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 "derivative"s 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 behav
[sage-devel] Re: harmonizing derivatives of symbolic expressions and polynomials
On Feb 24, 2008, at 1:49 PM, Fallen Seraph wrote: > The function I was interested in was: > > g(p,q) = 2*q(exp((q+p)^4)+1)+p(2*exp((q+p)^4)-1) It's not clear to me whether the first q is supposed to be multiplied by the following stuff, or whether q is supposed to be a *function* being evaluated at (exp((q+p)^4)+1). > h(p,q) = (2*q*exp((q+p)^4)+2*q)+p(2*exp((q+p)^4)-1) Here you are now multiplying q by exp(...). Do you also want to multiply p by 2*exp(...) in the second term, or is that a function evaluation? P.S. you should move this discussion to a different thread. I don't think it's that closely related to the "harmonizing derivatives..." thread. I am replying on this thread so that you can easily find this reply. 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
Okay So pretty much everyone seems to like the proposal, and from discussion on IRC and sage-devel we're going to use derivative() instead of diff(), which is fine with me. I'm going to start coding as soon as I discuss with martin about the have_ring parameter issues david On Feb 24, 2008, at 2:42 PM, Alex Ghitza wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I like the proposed plan. > > I also agree with Nick on derivative() vs diff(), but since the plan > says that both will be around, I can probably live with that. > > > Best, > Alex > --~--~-~--~~~---~--~~ 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. = 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. = 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] 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] "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] 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] 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: 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] 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. = 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 m>0
> 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: 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.=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. = 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] bug in factoring over number fields?
Is the following a bug? sage: K. = NumberField(x^2 + 1) sage: R. = 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] 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. = NumberField(x^2 + 1) >> sage: R. = 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. = 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. = 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: 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] 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] 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] 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] Re: trouble running n() on matrices
On Apr 9, 2008, at 12:24 AM, Robert Bradshaw wrote: >> >> Could this be a bit more general? There are other things one wants >> to do that are similar, such as matrix.real() and matrix.imag(), or >> matrix.abs() for real, imaginary, and absolute values of the entries >> respectively. It sounds like we want a map operator for a lot of >> datatypes. > > There is an apply_map function that will do this. I experimented with > making it automatic (i.e. if the method is not found, look up the > element's method) and it felt weird--interesting but I don't think > that's what we want to do. > > sage: M = matrix(3, [1+k^2 for k in range(9)]); M > [ 1 2 5] > [10 17 26] > [37 50 65] > > sage: M.valuation(5) > [0 0 1] > [1 0 0] > [0 2 1] > > sage: M.sqrt() # I'm sure this isn't what we want > [1 sqrt(2) sqrt(5)] > [ sqrt(10) sqrt(17) sqrt(26)] > [ sqrt(37) 5*sqrt(2) sqrt(65)] > > sage: M.ndigits() > [1 1 1] > [2 2 2] > [2 2 2] > > sage: M.next_prime() > [ 2 3 7] > [11 19 29] > [41 53 67] > > sage: M.multifactorial(7) > [ 1 1 1] > [10170 5928] > [ 3676320 5925744000 31101226041600] Ugh. I don't like any of them. Even valuation is wrong. 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: 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: > >> 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: Noncanonical coercion (finite fields)
On Apr 13, 2008, at 12:50 PM, Kiran Kedlaya wrote: > Any opinions about what > > sage: F9. = GF(9); F81. = 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. = GF(9) sage: F81. = GF(81) sage: F81(a) [.] : 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: 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: construction of finite fields GF(2^n)
On Apr 23, 2008, at 5:38 PM, Martin Albrecht wrote: > 3) search for a tri- or pentanomial with some code similar to the > one in blog > post You might want to check the NTL code for whether NTL "auto-detects" that you have supplied a sparse polynomial (and hence uses faster code for arithmetic), or whether you have to tell it explicitly. I vaguely remember that the preconditioned division struct has a flag for this, but I can't remember whether it gets set automatically. 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: Initial support for posets
On Apr 24, 2008, at 2:54 PM, root wrote: > > Axiom's "solution" to the lattice problem is to use an interpreter > for user interaction. Instead of just talking to a top level lisp > command prompt, you interact with the interpreter. > > The interpreter looks at the arguments and classifies them by type. > It looks for "modemaps" that define the functions (e.g. all lattice > functions) and finds a minimum type matching modemap. The process > is repeated "working outward" for the final expression type. > > Thus Axiom has some 1 functions with approximately 3000 names > in the name space. The user can explicitly override this process > in various ways. > > You might say lattice(args)$Posets to explictly override the > interpreter (although it will fail if the argument types don't > match). > > Given the limits of naming conventions by various fields of math, > the interpreter provides a way to overload names in useful and > naturals ways. Thus a single function (say, map) can have multiple > well defined meanings (there are 80 map functions in Axiom). > > In compiled code (Spad), you must specify exactly which function > of which domain you intend to call. If you're ambiguous about it, > the compiler gives you a suitably ambiguous error message. > > Perhaps someone might give some thought to a Sage-interpreter > that helps in name resolution rather than having 80 people > try to define which "map" is the "correct" map. I guess we would just use Python namespaces for this. For example, there might be two modules, sage.groups.abelian_group.lattice and sage.combinat.lattice. Then you would do something like sage: from sage.groups.abelian_group.lattice import Lattice or sage: from sage.cominat.lattice import Lattice depending on which Lattice you wanted to work with. I think the debate going on in this thread is more about which is the default one in the global namespace. I hate the global namespace, so I'm not going to get involved :-) 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: fast vs viable (offline post)
On Apr 30, 2008, at 6:38 PM, root wrote: > > David, > >>> 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 > > I've been associated with some open source projects, and in > particular, > with Axiom, Magnus, and Doyen. And I've been programming for 35 years. In the interests of full disclosure, Sage is the first open source project I've been seriously involved with, and I haven't even been alive for 35 years :-) > Once a week I hear the "I don't have enough time" argument. > > This argument is fine for most of the things I do, e.g. the things > I get paid to do because, frankly, almost nothing I've ever done will > be worth anything 10 years from now. > > Computational Mathematics is different in this respect. The answer > to integrate(sin(x),x) will be the same 30 years from now. However, > the expert who wrote the code will not. (Manual Bronstein is dead). > Who will maintain this code if it requires a PhD in Infinite Group > Theory just to understand WHY it works and a computer science degree > to understand what the PROGRAM is doing? > > The real tradeoff question is "Are you doing science?" or just > "playing around with ideas". Because, if you're doing science then > you're doing it for the community. Which means that there is a > standard of scholarship that is expected. > > When I read a proof of a new theorem I expect to see references > to prior results, complete proofs of lemmas, complete documentation > of assumptions, and a full explanation of the whys-and-wherefores. > It takes about 5-10 pages to reach this standard of publication > for most mathematics. And THAT TAKES TIME. > > So ask yourself the following question: > What is the "standard of publication" for COMPUTATIONAL mathematics? > > What *I* expect to see is an explanation of the mathematics, possibly > with proofs (if new). I expect an explanation of how and why the CODE > implements the mathematics. I expect complexity bounds. I expect an > explanation of optimizations that are not obvious but are critical. > This may take 10-100 pages to reach this standard of publication for > computational mathematics. and THAT TAKES TIME. > > If you haven't given me that level of documentation then you haven't > given me anything but your lab notebook. You've published nothing but > your scribblings to yourself with no assurance that (a) it is > mathematically > sound, (b) it is correct, and (c) the who/what/where basis for your > work is anything but your own self-mutterings. > > Do we build a science on this? No, I agree we can't build a science on this. But you still haven't told me: where is all this time going to come from? I can't magically make more time appear. I have other things to do. It's a damn shame. (Oh this reminds me of a wonderful novel by Michael Ende called "Momo", about a town that gets invaded by strange evil men in grey suits who trick everyone into putting their time in a special "time bank", and of course they never get their time back. Momo is a little girl who saves the world. Highly recommended.) > A few centuries ago a mathematician could claim anything by > handwaving, and "prove it" by solving the questions posed to him. > > In the last century the standard of proof has risen in mathematics > from handwaving, thru simple explanations, and eve
[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: 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: 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: Computing large Bernoulli numbers
One more data point (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 sage: time x = bernoulli(96) Wall time: 2436.06 The ratios between successive times are: 4.47757255936675 6.96758986446671 4.56909675236806 4.50913465987969 If we guess that it's "really" 4.5, then the complexity is N^(log (4.5) / log(2)) = N^2.17. This is puzzling; I thought the algorithm was supposed to be better than quadratic. Does anyone know what the theoretical complexity is supposed to be? Anyway, extrapolating gives about 4.5 days, pretty much the same as what Tom estimates. I'm going to start it running now. 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 -~--~~~~--~~--~--~---
