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. 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. >