Re: atan2_sharp() -- a Motion?

["Corliss, George" <george.corliss@xxxxxxxxxxxxx>]

Friends,

My preference is not to include atan2_sharp(), in the interests of KISS.  Nothing prevents an implementation from providing it, nor does anything prevent a programmer from developing exactly what is needed for an application at hand.

We do not need to finish all advances in interval arithmetic, but we DO need to finish this standard, or we have no standard.

George Corliss


On Feb 26, 2014, at 9:00 AM, John Pryce <j.d.pryce@xxxxxxxxxx> wrote:

> 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



George Corliss
George.Corliss@xxxxxxxxxxxxx

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail