Re: New ellinit interface

[John Cremona <john.cremona@gmail.com>]

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.

John

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
<Bill.Allombert@math.u-bordeaux1.fr> 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.
>