Search All of the Math Forum:

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

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

 Messages: [ Previous | Next ]
 Waldek Hebisch Posts: 267 Registered: 12/8/04
Re: Bug in Jacobian Amplitude?
Posted: Apr 8, 2013 1:51 PM

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

> >
> > Well, this equation can be used to define 'am'. Together with
> > value at single point and cuts you get full definition. Note
> > that the only problem with solving this equations is at poles
> > of 'sn' (which are the same as poles of 'cn'). The other
> > potentially troublesome point is 0, but 'sn' and 'cn' never
> > vainish together, so this is excluded.
> >
> > The nasty part is complex 'k'. Or in notation I prefer 'm'.
> > When 'm' varies angle between periods changes so if you
> > use halflines in 'z' plane for cuts they will change direction
> > with changing 'm'.
> >
> > Let me add that in FriCAS I did not impement 'am' precisely
> > because cuts are so arbitrary: FriCAS code would have to
> > spent effort to get on the defined sheet and then for
> > user any fixed choice of cuts may be wrong, so the user
> > probably would have to redo the work on cuts to get
> > them as he/she needs.
> >
> > I wonder what use Did has of 'am' for complex arguments,
> > that should give some hints which cuts (if any) would
> > be good for him.
> >

>
> Thanks, without means to experiment I preferred to tread carefully.
>
> 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.

> 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)

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...

--
Waldek Hebisch
hebisch@math.uni.wroc.pl

Date Subject Author
4/2/13 did
4/2/13 Nasser Abbasi
4/2/13 did
4/2/13 clicliclic@freenet.de
4/3/13 did
4/4/13 clicliclic@freenet.de
4/4/13 Waldek Hebisch
4/5/13 clicliclic@freenet.de
4/5/13 did
4/6/13 clicliclic@freenet.de
4/7/13 Waldek Hebisch
4/8/13 clicliclic@freenet.de
4/8/13 Waldek Hebisch
4/9/13 clicliclic@freenet.de
4/13/13 clicliclic@freenet.de
4/8/13 Axel Vogt
4/3/13 Joe keane