
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

