Re: atan2_sharp() -- a Motion?
Michel, Lee, P1788
On 2014 Feb 25, at 15:05, Michel Hack wrote:
> John Pryce wrote:
>> If people have no objection to such a function, let's have a motion.
>
> I was going to propose a simple motion that sort of side-steps the issues,
> namely to suggest adding atan2m() and atan2p() to the list of recommended
> operations in 10.7 (Table 10.6), with Note g referring to a new subsection,
> either 10.7.2 (shifting others) or 10.7.1.1 (insertion only):
>
> 10.7.1.1. atan2_sharp()
>
> One issue with the interval extension of the standard atan2() function,
> with range (-pi,+pi], is that a tight input box that straddles the x axis
> on the negative side would like to return a tight result that includes
> either -pi or +pi. But with the atan2() range this is not possible, and
> atan2() would have to return a maximally-wide result of [-pi,+pi].
>
> By allowing a choice of branch cut, either atan2m() with range (-2pi,0]
> or atan2p() with range [0,+2pi), a programmer can construct a sharp
> version of atan2. (Nevertheless an actual atan2_sharp() function is not
> recommended, because (a) such a function is technically not an interval
> extension of one point function, and (b) there is no generally-useful
> fixed rule for choosing a branch cut based on a given input box.
>
> But then it occurred to me that atan2m() and atan2p() are not the only
> choices. Any rule that selects among two or three fixed branch cuts
> suffers from the problem that, as a tight input box slides across the
> point where the branch cut choice is made, the result jumps by 2pi.
>
> What we want is a branch cut choice where the cross-over point is far
> from the expected result.
>
> So perhaps what we need is atan3(yy,xx,m) where m is an estimate of the
> expected result midpoint (think of it as a parameter rather than as a
> third interval input). The programmer could then implement atan2_sharp()
> by using context information about the expected result, and pick the
> appropriate m for atan2_sharp(yy,xx) = atan3(yy,xx,m). This will pick
> a branch cut such that the range of atan3(yy,xx,m) is (m-pi,m+pi].
>
> Is that reasonable? People who regularly program with branch cuts,
> please chime in, because I don't.
Here is an application. Consider numerically solving a (regular) Sturm-Liouville eigenvalue problem
-(p(x) y'(x))' + q(x) y(x) = L w(x) y(x) on a <= x <= b with suitable BCs at a and b
where p, q, w are given functions and L means \lambda, the eigenparameter.
The k-th eigenvalue L_k is the one whose eigenfunction y_k has k zeros on the open interval. One way to find it uses the fact that the path
(y, py')(x)
in the plane essentially winds k times in +ve direction round the origin O.
So, say, starting with given (y,py')_0 at x = x_0 = a, an ODE integrator computes a sequence of points w_n = (u_n,v_n) = (y,py')_n at x=x_n, n=0,1,2,...
Now suppose we do this with a validated integrator. Then we have a sequence of boxes
ww_n = (uu_n, vv_n)
where each uu and vv is a real interval. Assume we do it sufficiently accurately that no box contains O. Then if we take small enough steps it is unambiguous which way round O w_n is rotating in any interval [x_{n-1},x_n], and how far.
[For 1-D Schroedinger equations with energy wells and barriers, the direction of rotation may go negative for part of the x-range.]
So how do we make it convenient for the user to convert a sequence of ww_n into a sequence of ttheta_n, being intervals containing the polar angle theta_n of the rotating point?
It seems to me something like Michel's 3-argument atan3 may make most sense, the m being an estimate of the current theta value. The others are probably usable, but less convenient. Any ideas?
John