Re: atan2_sharp() -- a Motion?
John Pryce wrote:
> Am I right: for any invocation of the interval version, zz = Atan2(yy,xx)
> where O not in R=(xx,yy), there is an unambiguous 1-valued branch that is
> defined and continuous on a neighbourhood of R, and this is what we use
> in the FT(D)IA?
Yes. I expect atan2_sharp() to be the interval extension of one of the
three single-valued branches atan2, atanp and atanm with respective ranges
(-pi,+pi), (0,+2pi) and (-2pi,0), where the atan2 is the one already in
our list. I keep changing my mind as to whether three or just two are
needed, and need to think a bit more about it to ensure that I can match
the rule suggested by Bill Walster, namely to ensure that the midpoint
of the result is in (-pi,+pi).
The FT(D)IA applies to functions built using the case() function, right?
What I'm not certain of at this point is whether the rules I am thinking
of could be built on nothing but functional composition including the
case function -- and if not, there may indeed be an issue.
If 0 is included in both xx and yy, I would pick the regular atan2(),
and return an enclosure of [-pi,+pi] -- though a case could be made
for returning the union of the two or three ranges mentioned above.
And yes, a decoration should be trv.
An unavoidable problem seems to be that when a narrow and tall vertical
box slides across the y axis, the result would flip from something close
to [-pi/2,+pi/2] to something close to [+pi/2,+3pi/2].
> - Or a suitably smaller interval when O is on the boundary of R,
> e.g. zz = [0,\pi/2] for R = ([0,1],[0,1]) ?
Interesting observation. I wish somebody who actually uses interval
arithmetic and atan2() could chime in, because I'm approaching this
subject from the outside, and only have my geometric intuition to
follow. I got involved in this because I think Bill Walster has a
point when he says that atan2() as currently specified in P1788 would
be unusable, and I would not want somebody's sensible implementation
of atan2_sharp() to be deemed incompatible.
Somebody pointed out that there may be reasons why the strict atan2()
that is the interval extension of a single atan2() function may be
essential too, and this interval version should therefore be required,
at which point any suitable atan2_sharp() would simply be an additional
function supported by the implementation, perhaps under the name ATAN2
with the 1788-version called ATAN2_1788, and everybody would be happy.
Michel.
---Sent: 2014-02-10 19:14:30 UTC