atan2_sharp() again: atan3(y, x, n)
Having now seen the layout of the P1788 draft as it is converging to
its final form, I have identified the place where to deal with this
issue: Section 10.6, Recommended operations. I suggest a separate
subsection 10.6.2 (or perhaps 10.6.1.1, as it would still be a
forward-mode elementary function):
10.6.1.1 Sharp enclosures for atan2()
One issue with the standard atan2() function is that it picks a
fixed branch cut (-pi,+pi] (or, perhaps more easily visualized
for atan2Pi(), of (-1,+1]) for the result. The input box may be
such that a different branch cut (e.g. (-2pi,0]) would yield a
narrow result centered around -pi, but where the standard atan2()
would have to return an enclosure of [-pi,+pi], which is as wide
as possible and loses all information.
An implementation should provide the functions atan3(y,x,n) and
atan3Pi(y,x,n) with ranges ((n-1)pi, (n+1)pi] and ((n-1), (n+1)]
respectively, where the integer parameter n selects the branch cut.
Rationale (I'm not quite sure this is right):
This would allow a progressive-refinement algorithm to chase the
convergence point across a cut boundary without catastrophic widening.
The parameter n could be derived from floor(mid(previous_result)/pi),
or simply from floor(mid(previous_result)) for atan3Pi(), for example.
For each fixed n, the interval function atan3(y,x,n) is an interval
extension of an arithmetic point function, and the full FTDIA applies.
Michel.
P.S. Would there be any reason to use a finer cut granularity, e.g. pi/2?
My earlier suggestion of atan3() with the third argument a real
that is to be included in the result had continuous granularity,
but raised a number of issues of its own.
---Sent: 2014-04-30 14:14:21 UTC