e1e2e3: Calculate e1, e2, e3 from the invariants
In elliptic: Weierstrass and Jacobi Elliptic Functions

Description Usage Arguments Value Note Author(s) References Examples

Calculates e1,e2,e3 from the invariants using either polyroot or Cardano's method.

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

`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: P(omega1), P(omega2), P(omega3). 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 in the right order (the roots are found according to the vagaries of `polyroot()`)
`AnS`	Boolean, with default `TRUE` meaning to define omega3 as per ams-55, and `FALSE` meaning to follow Whittaker and Watson, and define omega1 and omega2 as the primitive half periods, and omega3=-omega1-omega2. 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

Returns a three-element vector.

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) e1, e2, e3.

There is considerable confusion about the order of e1, e2 and e3, 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 e1=P(omega_1/2), e2=P(omega_3/2), e3=P(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 (omega1,omega3) as a primitive pair, and to require omega2=-omega1-omega3. 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 “omega2” to be really omega3, and what this package calls “omega1+omega2” to be really omega2. 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.

Robin K. S. Hankin

Mathematica

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

Attaching package: 'elliptic'

The following objects are masked from 'package:stats':

    sd, sigma

The following object is masked from 'package:base':

    is.primitive

[1] 0+0i