> I hope you are right, as that would be good news -- it used to have
> greater overheads. On the other hand, in your tests you were reusing
> the same large finite field many times, and using large fields, wheras
> the typical case for me (e.g. for evaluating L-functions) is to get
> E.ap(p) for all p up to some bound, hence thousands of finite fields
> being constructed by negligible time for the point-counting.
sage: %time _ = [EllipticCurve(j=123456).ap(p) for p in primes(1000)]
CPU times: user 2.7 s, sys: 22.8 ms, total: 2.72 s
Wall time: 2.7 s
sage: %time _ = [c(EllipticCurve(j=123456), p) for p in primes(1000)]
CPU times: user 2.7 s, sys: 19.7 ms, total: 2.72 s
Wall time: 2.69 s
where c is defined as
def c(E,p):
try:
return E.change_ring(p).cardinality()
except:
return 0
(the curve may be singular mod p).
> Secondly, in the number field case the finite fields are constructed
> as residue fields which are slower (I think) than forming an abstract
> GF(q).
Quite possible, although in the end residue fields are just wrappers
around finite fields, so they shouldn't be that bad. Here's a silly
and not very meaningful example
sage: sage: K.<i> = QuadraticField(-1)
sage: sage: E = EllipticCurve([1+i,i,i,0,0])
sage: %time _ = [E.reduction(K.prime_above(p)).cardinality() for p
in primes(1000) if p % 4 == 1]
CPU times: user 564 ms, sys: 4.08 ms, total: 568 ms
Wall time: 553 ms
sage: %time _ =
[E.reduction(K.prime_above(p)).change_ring(GF(p)).cardinality() for p
in primes(1000) if p % 4 == 1]
CPU times: user 613 ms, sys: 16.1 ms, total: 629 ms
Wall time: 623 ms
I'm not saying that it wouldn't be useful to extend ap() as you suggest, though.
Luca
--
You received this message because you are subscribed to the Google Groups
"sage-nt" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send an email to [email protected].
Visit this group at http://groups.google.com/group/sage-nt.
For more options, visit https://groups.google.com/d/optout.
