Re: atan2_sharp() -- a Motion?
Michel, P1788
Sorry for slow response.
On 2014 Feb 10, at 18:24, Michel Hack wrote:
> 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.
I don't think it can be. The case() function is a (one valued) point arithmetic operation. OK, it is given an unusual interval extension, to support "short-circuit" evaluation, but I don't think that gives this extension the global nature -- looking at whether the input (xx,yy) meets both quadrants 2 and 3, [thinking of it as phase(x,y), not atan2(y,x)] -- that this operation requires.
> 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.
I'm against an "atan2ToPair". At this late stage we couldn't discuss it properly & it looks like over-egging the cake.
> 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,
Yes, please.
> ...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.
Yes. I think this strict (but crude) version should be the main one, and be called atan2().
Anyway, please go ahead and submit a motion plus rationale.
John