e1e2e3.RdCalculates \(e_1,e_2,e_3\) from the invariants using
either polyroot or Cardano's method.
e1e2e3(g, use.laurent=TRUE, AnS=is.double(g), Omega=NULL, tol=1e-6)
eee.cardano(g)Two-element vector with g=c(g2,g3)
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())
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
A pair of primitive half periods, if known. If supplied, the
function uses them to calculate approximate values for the three
\(e\)s (but supplies values calculated by polyroot(),
which are much more accurate). The function needs the approximate
values to determine in which order the \(e\)s should be, as
polyroot() returns roots in whichever order the polynomial
solver gives them in
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) \(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.
Mathematica