John Cremona on Sat, 20 Oct 2012 17:19:32 +0200

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: New ellinit interface

This sounds reasonable, and is (not surprisingly) very close to the
heierarchy of differen elliptic curve classes in Sage ("class" being
the python term).  Sage has another, below your t_ELL_Rg and above all
of t_ELL_{Q,Qp,...}, namely an equivalent to t_ELL_Field.  There are
some generic operations which can be done over a ring, but others
which require division so should be done over a field.  I just took a
look, and the functionality at that level in Sage (requiring a base
field, but not any specific field) includes: quadratic and higher
twists, isogeny operations,  and a few other things.  It is not a
completely logical separation, for example j_invariant is at the level
of rings, despite requiring a division.

Anyway, you may want to consider added a type for elliptic curves over
a general field.


PS For those of you who are waiting impatiently, I have precisely one
remaining conductor currently computing before my database reaches
conductor 300,000.

On 20 October 2012 16:02, Bill Allombert
<> wrote:
> On Tue, Oct 16, 2012 at 10:38:30PM +0200, Bill Allombert wrote:
>> Dear PARI developers,
>> Karim and I have been discussing about change to ellinit to make it more useful
>> and to replace ellffinit.
> So we have decided about a new format for ellinit output (ell object)
> I have implemented part of it.
> Choice I have made we did not explicitly decide are prefixed by a *
> * ell objects will always have 16 components so smallellinit will disappear.
> (ellinit(,0) and ellinit(,1) are deprecated and are equivalent to ellinit()).
> components 1 to 13 are the same as for smallellinit.
> 14 is the type, 15 are the type-specific data, 16 are the extended data.
> currently my implementation supports the following types:
> * t_ELL_Rg: general rings, substitute for smallellinit.
> Only basic operations are available.
> t_ELL_Q: curves over Q. (Is it easy to find an integral, (possibly non minimal) model ?)
> t_ELL_Qp: curves defined over Q, seen over Qp.  (not supported yet)
> t_ELL_Fp: curves over F_p
> t_ELL_Fq: curves over F_q
> Note that there is no curves over R or C. It is almost always better to define such
> curves by their periods than by a Weierstrass equation.
> ellffinit will be removed.
> Reductions:
> We frequently want to reduce an elliptic curve over Z to an curve over F_p,
> for some p. The simplest way to do that is Ep=ellinit(E,p).
> Unfortunately this leads to some pathology:
> 1) Such reduced curve can be singular. A priori we will not
> allow ellinit to define singular curves over F_p.
> 2) The prime number can be passed implicitly, for example when asked about the
> order of a point defined over Fp on a curve defined over Z: e.g.
> ellorder(ellinit([0,0,0,1,2]),[Mod(13,17),Mod(11,17)])
> 3) We still want the ability to compute local invariants at primes of bad reduction.
> sometimes both 1,2 and 3) happens. Do we want to allow ellorder on singular curves:
> ellorder(ellinit([0,0,0,1,5]),[41,0]*Mod(1,97))
> Coordinate changes:
> ellchangecurve must be careful to update the type specific and the extended data
> correctly.
> Cheers,
> Bill.