Drexel dragonThe Math ForumDonate to the Math Forum

Search All of the Math Forum:

Views expressed in these public forums are not endorsed by NCTM or The Math Forum.

Math Forum » Discussions » sci.math.* » sci.math.symbolic

Topic: Bug in Jacobian Amplitude?
Replies: 16   Last Post: Apr 13, 2013 1:35 PM

Advanced Search

Back to Topic List Back to Topic List Jump to Tree View Jump to Tree View   Messages: [ Previous | Next ]

Posts: 1,099
Registered: 4/26/08
Re: Bug in Jacobian Amplitude?
Posted: Apr 9, 2013 12:04 PM
  Click to see the message monospaced in plain text Plain Text   Click to reply to this topic Reply

Waldek Hebisch schrieb:
> clicliclic@freenet.de wrote:

> >
> > So there will never be a conflict with sn(u,k) = sin(am(u,k)) and
> > cn(u,k) = cos(am(u,k)) whatever one's choice of branch cuts: at the cuts
> > am(u,k) cannot but jump in steps of 2*pi. So Mathematica doesn't just
> > implement am(u,m) for some unsuitable choice of cuts, it doesn't really
> > implement the Jacobi amplitude.

> Well, I did not see Jacobi paper so I do not not what his definition
> was, but DMLF 22.16.1 says
> am(x,k)=Arcsin(sn(x,k)),
> where the inverse sine has its principal value when -K<= x <= K and
> is exended by continuity elsewere. Of course this make sense
> for real x. If you naively extend this definition to complex
> plane you violate cn(u,k) = cos(am(u,k)). OTOH cn(u,k) = cos(am(u,k))
> is 22.16.13, so clearly DMLF editors have relaxed view about
> consistency of their formulas...
> Anyway, my point is that 'am' is rather poorly defined in the
> literature.

As a multivalued function C->C it is (of course) completely defined, but
CAS implementors seem to have been terribly lazy about defining a
"standard" branch. More below ...

> > And so at least for real K, Maple's
> > am(u,k) can be made continuous on the real line by adding steps of size
> > 2*pi where Re(u) equals 2*m*K, which makes one wonder if Maple's am(u,k)
> > could in fact be disconnected.
> >
> > I would consider it a natural choice if the pattern of branch cuts for
> > complex K and K' moves along with the lattice of branch points. While
> > this is likely to introduce discontinuities on the real line, continuity
> > would be preserved along the 'm' diagonal in the complex plane. And I am
> > not at all pessimistic as to the uses of am(u,k) for a good, fixed
> > (maybe even standardized) choice of branch cuts (that is, cuts along the
> > +m, -m, +n, or -n directions, I wouldn't seriously contemplate diagonal
> > orientations). How else is a CAS going to evaluate INT(dn(u,k),u)?

> Hmm, in FriCAS:
> (14) -> D(-atan(jacobiCn(z, m)/jacobiSn(z, m)), z)
> (14) jacobiDn(z,m)
> Type: Expression(Integer)

I see :). -atan(cn(z,m)/sn(z,m)) will be a valid antiderivative of
dn(z,m) too. Its disadvantage are unnecessary discontinuities, which
also disqualify it as a definition of a "standard" branch for am(z,m).
More below ...

> If you want to evaluate numerically definite integrals along a
> patch you need to make sure that path do not cross brunch cuts
> or patch the results together. ATM in FriCAS users have to
> do this manually. However, I am thinking abot new operation
> say 'AnalyticContinuation(f, z0)' which would specify that
> given formula 'f' should be used at 'z0' and continued
> analytically elsewere. This should be enough if 'f' has
> single valued continuation. In case there are brunch points
> one would have to give path, and it is not clear for me
> when/how to specify paths...

My mind boggles at the idea of functions (presumably as specified by
some CAS expression) that are in need of analytic continuation
(presumably because a branch cut of a predefined function in the
expression intervenes) but do not possess a branch point - though that
may be just from spring having arrived. On the other hand, I can easily
conceive of the specification of (e.g. integration) paths in the complex
plane, e.g. as an interval [x,a,b] on the real line, or as a polygonal
line [z,a,b,...,g] traversing the plane, or as a parametrized line z(t)
where z is some complex function for a real interval [t,0,1].


If DLMF claims that it is working in an "all function symbols C->C refer
to single predefined branches only" paradigm, then their equations are
incompatible and therefore partly wrong. I my experience, 19th century
literature wasn't generally meant to comply with this paradigm and so
the branches referred to were often undefined or not uniquely defined. I
wouldn't expect too much from looking up Jacobi about his choice of
branch cuts or about branch-cut correct functional equations for his
amplitude function - not much more than from looking up Jonquière or
Lerch about branch-cut correct equations for the polylogarithm and
Lerch's transcendent. Even their complex logarithm was usually
incompatible with the present definition.

For obvious reasons, no choice of "standard branch" for some function
C->C should cut up the function unnecessarily, in particular not cut it
completely into two: for any two valid complex arguments there must
remain a connecting path along which the function is analytic. For
Jacobi's am(u,k), the unavoidable cuts are those beginning or ending at
each of its branch points, the latter being an unalterable property of
the function itself. Since the residues of the poles of dn(u,k)
compensate each other pairwise, I expect that cuts for am(u,k) may start
at one branch point and stop at another: they wouldn't have to go on to
infinity. Assuming straight lines between neighboring branch points,
this doesn't leave unmanageably many possibilities. A preference for
certain functional equations might help narrow down the choice further.

But I am tiring of building castles in the sky - it is up to the CAS
implementors to work this out. And it is up to Did now to delineate his


Point your RSS reader here for a feed of the latest messages in this topic.

[Privacy Policy] [Terms of Use]

© The Math Forum at NCTM 1994-2016. All Rights Reserved.