Karim Belabas on Sat, 20 Oct 2012 21:23:17 +0200 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: New ellinit interface |
* Bill Allombert [2012-10-20 17:03]: > 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 ?) Yes it is: ellintegralmodel uses only a partial factorization of involved denominators. > 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 We're missing t_ELL_K: curves over number fields t_ELL_Kv: curves over local fields (completion of #field K at prime v) almost nothing is implemented yet [ we have the ellnflocalred() script, Francois Brunault's implementation of Tate reduction algorithm; my new elltors() code using division polynomials can also trivially be adapted to handle torsion over number fields ]. It would be a pity not to include this, given PARI's current strong points in algebraic number theory. And we want to include Denis Simon script as well :-) > 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. I started implementing this with a view to compute complex elliptic functions (any other application ???). Here's my current specification ellperiods(w, {flag = 0}): w = [w1,w2] describes a complex period lattice. \\ (1). I decided not to allow an ellinit here Returns normalized periods [W1,W2] generating the same lattice such that tau := W1/W2 satisfies Im(tau) > 0 \\ (2). Is it useful to include the Gl_2(Z) base change matrix ? \\ Probably not. If flag is non-zero, the return value is [[W1,W2], [eta1,eta2]], where eta1, eta2 are the quasi-periods associated to [W1,W2]. The output of this function is meant to be used as the first argument given to ellwp, ellzeta, ellsigma or elleisnum. Quasi-periods are needed by ellzeta and ellsigma only. A question: computing eta1,et2 is currently done via E_2 (and Legendre relation). Even for tau in the standard fundamental domain, computing E_2(tau) in terms of \sum_{n>0} n q^n / (1-q^n) is expensive, in O~(prec^2), assuming quasi-linear multiplication. Can one do better ? Cheers, K.B. -- Karim Belabas, IMB (UMR 5251) Tel: (+33) (0)5 40 00 26 17 Universite Bordeaux 1 Fax: (+33) (0)5 40 00 69 50 351, cours de la Liberation http://www.math.u-bordeaux1.fr/~belabas/ F-33405 Talence (France) http://pari.math.u-bordeaux1.fr/ [PARI/GP] `