Testing this with 2^31 replaced by 2^30 revealed a serious efficiency bug which has been fixed now (trac #2659), which might make it into 2.11. If you try your example (with 2^30 in place of 2^31) you will find that the abelian_group() command takes a very long time, similarly computing orders of points, but after the fix those both work very quickly.
John Cremona On 21 Mar, 18:44, "William Stein" <[EMAIL PROTECTED]> wrote: > On Fri, Mar 21, 2008 at 9:44 AM, seventeener <[EMAIL PROTECTED]> wrote: > > > Hello, I'm using v.2.10.3 on a 32-bit machine under VMware. I'm unable > > to define an elliptic curve over a non-prime finite field of > > characteristic longer than 31 bit: > > > EllipticCurve(GF(next_prime(2^31)^2,'x'),[1,1]) > > > Traceback (most recent call last): > > File "<stdin>", line 1, in <module> > > File "/home/notebook/sage_notebook/worksheets/admin/12/code/10.py", > > line 6, in <module> > > EllipticCurve(GF(next_prime(Integer(2)**Integer(31))**Integer(2), > > \u0027x\u0027),[Integer(1),Integer(1)]) > > File "/usr/local/sage/local/lib/python2.5/site-packages/sympy/ > > plotting/", line 1, in <module> > > > File "/usr/local/sage/local/lib/python2.5/site-packages/sage/schemes/ > > elliptic_curves/constructor.py", line 115, in EllipticCurve > > return ell_finite_field.EllipticCurve_finite_field(x, y) > > File "/usr/local/sage/local/lib/python2.5/site-packages/sage/schemes/ > > elliptic_curves/ell_finite_field.py", line 75, in __init__ > > EllipticCurve_field.__init__(self, ainvs) > > File "/usr/local/sage/local/lib/python2.5/site-packages/sage/schemes/ > > elliptic_curves/ell_generic.py", line 145, in __init__ > > x, y, z = PP.coordinate_ring().gens() > > File "/usr/local/sage/local/lib/python2.5/site-packages/sage/schemes/ > > generic/projective_space.py", line 190, in coordinate_ring > > self.variable_names(), self.dimension()+1) > > File "/usr/local/sage/local/lib/python2.5/site-packages/sage/rings/ > > polynomial/polynomial_ring_constructor.py", line 248, in > > PolynomialRing > > R = _multi_variate(base_ring, names, n, sparse, order) > > File "/usr/local/sage/local/lib/python2.5/site-packages/sage/rings/ > > polynomial/polynomial_ring_constructor.py", line 369, in > > _multi_variate > > R = MPolynomialRing_libsingular(base_ring, n, names, order) > > File "multi_polynomial_libsingular.pyx", line 235, in > > > > sage.rings.polynomial.multi_polynomial_libsingular.MPolynomialRing_libsingular.__init__ > > OverflowError: long int too large to convert to int > > The problem lies here: > > sage: k = GF(next_prime(2^31)^2,'x') > sage: k['y,z'] > Traceback (most recent call last): > ... > OverflowError: long int too large to convert to int > sage: PolynomialRing(k,2,'x,y') > Traceback (most recent call last): > ... > OverflowError: long int too large to convert to int > > This is caused because Sage is trying to use libsingular > to create the poly ring, but should be using its own code > when the size of the base ring is too big. > > Martin Albrecht will be able to fix this very easily. I've made > a trac ticket: > > http://trac.sagemath.org/sage_trac/ticket/2634 > > William --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-support@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-support URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
