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 ?


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]