2008/9/21 Georg S. Weber <[EMAIL PROTECTED]>:
>
> Hi John,
>
> On 21 Sep., 21:16, "John Cremona" <[EMAIL PROTECTED]> wrote:
>> The long test in ell_finite_field.py which causes problems on this
>> platform is this:
>> sage: E = EllipticCurve('389a')
>> sage: for p in prime_range(10000): #long time (~20s)
>> ... if p != 389:
>> ... G=E.change_ring(GF(p)).abelian_group()
>>
>> I would like to know if there is something going on there which can be fixed.
>>
>> Can you test these and see if they work:
>>
>> sage: for p in prime_range(10000):
>> ... if p != 389:
>> ... F=GF(p)
>>
>> and
>>
>> sage: for p in prime_range(10000):
>> ... if p != 389:
>> ... Ep=E.change_ring(GF(p))
>>
>> and
>>
>> sage: for p in prime_range(10000):
>> ... if p != 389:
>> ... G=E.change_ring(GF(p)).cardinality()
>>
>> Thanks,
>>
>> John
>
> the following line works fine:
>
> sage: for p in prime_range(10000):
> ... if p != 389:
> ... F=GF(p)
>
>
> as does that one (note the 3000 instead the 10000):
>
> sage: for p in prime_range(3000): #long time
> (~20s)
> ... if p != 389:
> ... Ep = E.change_ring(GF(p))
>
>
> but now with 4000 (yet no 10000) it fails:
>
> sage: for p in prime_range(4000): #long time
> (~20s)
> ... if p != 389:
> ... Ep = E.change_ring(GF(p))
>
>
> with the following message:
> ...
> sage -t -long devel/sage/sage/schemes/elliptic_curves/
> ell_finite_field.py
> halt 14
>
> error: no more memory
> System 5112k:5112k Appl 4598k/513k Malloc 4082k/5k Valloc 1024k/508k
> Pages 144/112 Regions 2:2
>
> A mysterious error (perphaps a memory error?) occurred, which may have
> crashed doctest.
> [37.2 s]
> exit code: 768
>
> ----------------------------------------------------------------------
> The following tests failed:
>
>
> sage -t -long devel/sage/sage/schemes/elliptic_curves/
> ell_finite_field.py
> Total time for all tests: 37.2 seconds
> ...
>
> Mysteriously, monitoring the RAM footprint during this half minute,
> nothing strange seems to happen. Of the 2 GB physical memory, more
> than 1.3 GB RAM is free at minimum all the time. Of the virtual RAM of
> the Sage processes, there is one python process of some 360 MB or so,
> and one gp processes of 600 MB or so, but that's it essentially.
> Monitoring this half minute with "3000" as a prime boundary instead of
> "4000" does not show any difference to me, especially the RAM
> footprint of all the processes involved is the same (300+MB python,
> 600+MB gp), apart from passing the test :-).
>
> For completeness, the following passes (the original line with only
> "3000" instead of "10000"):
>
> sage: for p in prime_range(3000): #long time
> (~20s)
> ... if p != 389:
> ... G=E.change_ring(GF(p)).abelian_group()
>
>
> So, "E.change_ring(GF(p))" is somehow the culprit, being called for
> primes p up to 4000 (or 10000) instead of only up to 3000.
> I' m curious if you can make sense of this --- I'll be online again
> tomorrow evening.
Right, so it's not the creation of the finite fields GF(p) which is
causing trouble, and neither is it the code in abelian_group() (good
-- that's the bit I wrote).
The change_ring() function just creates a new elliptic curve each
time. So you should see the same behaviour if you replace
Ep = E.change_ring(GF(p))
with
Ep = EllipticCurve(GF(p),[0,1,1,-2,0])
in the loop. To test this without having to avoid p=389 try this:
sage: for p in prime_range(100000): EllipticCurve(GF(p),[0,1,1,10,13])
(That curve will be ok for all p!=100931).
John
>
> Cheers,
> gsw
> >
>
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---
