e1e2e3 {elliptic}

Calculate e1, e2, e3 from the invariants

Description

Calculates e_1,e_2,e_3 from the invariants using either polyroot or Cardano's method.

Usage

e1e2e3(g, use.laurent=TRUE, AnS=is.double(g), Omega=NULL, tol=1e-6)
eee.cardano(g)

Arguments

g

Two-element vector with g=c(g2,g3)

use.laurent

Boolean, with default TRUE meaning to use P.laurent() to determine the correct ordering for the e: \wp(\omega_1), \wp(\omega_2), \wp(\omega_3). Setting to FALSE means to return the solutions of the cubic equation directly: this is much faster, but is not guaranteed to find the e_i in the right order (the roots are found according to the vagaries of polyroot())

AnS

Boolean, with default TRUE meaning to define \omega_3 as per ams-55, and FALSE meaning to follow Whittaker and Watson, and define \omega_1 and \omega_2 as the primitive half periods, and \omega_3=-\omega_1-\omega_2. This is also consistent with Chandrasekharan except the factor of 2.

Also note that setting AnS to TRUE forces the e to be real

Omega

A pair of primitive half periods, if known. If supplied, the function uses them to calculate approximate values for the three es (but supplies values calculated by polyroot(), which are much more accurate). The function needs the approximate values to determine in which order the es should be, as polyroot() returns roots in whichever order the polynomial solver gives them in

tol

Real, relative tolerance criterion for terminating Laurent summation

Value

Returns a three-element vector.

Note

Function parameters() calls e1e2e3(), so do not use parameters() to determine argument g, because doing so will result in a recursive loop.

Just to be specific: e1e2e3(g=parameters(...)) will fail. It would be pointless anyway, because parameters() returns (inter alia) e_1, e_2, e_3.

There is considerable confusion about the order of e_1, e_2 and e_3, essentially due to Abramowitz and Stegun's definition of the half periods being inconsistent with that of Chandrasekharan's, and Mathematica's. It is not possible to reconcile A and S's notation for theta functions with Chandrasekharan's definition of a primitive pair. Thus, the convention adopted here is the rather strange-seeming choice of e_1=\wp(\omega_1/2), e_2=\wp(\omega_3/2), e_3=\wp(\omega_2/2). This has the advantage of making equation 18.10.5 (p650, ams55), and equation 09.13.27.0011.01, return three identical values.

The other scheme to rescue 18.10.5 would be to define (\omega_1,\omega_3) as a primitive pair, and to require \omega_2=-\omega_1-\omega_3. This is the method adopted by Mathematica; it is no more inconsistent with ams55 than the solution used in package elliptic. However, this scheme suffers from the disadvantage that the independent elements of Omega would have to be supplied as c(omega1,NA,omega3), and this is inimical to the precepts of R.

One can realize the above in practice by considering what this package calls “\omega_2” to be really \omega_3, and what this package calls “\omega_1+\omega_2” to be really \omega_2. Making function half.periods() return a three element vector with names omega1, omega3, omega2 might work on some levels, and indeed might be the correct solution for a user somewhere; but it would be confusing. This confusion would dog my weary steps for ever more.

Author(s)

Robin K. S. Hankin

References

Mathematica

Examples

 sum(e1e2e3(g=c(1,2)))