Re: atan2_sharp() -- a Motion?
On 2014 Feb 20, at 22:08, Michel Hack wrote:
> Earlier I wrote:
>>> On whether atan2_sharp() can be programmed using case() and the two
>>> or three shifted-range atan2x() functions: I suppose I should try,
>>> and identify the sticking point.
>
> Here is the sticking point: If case() is used to select from two
> branches of atan2(), the fuzzy case (where the discriminator contains
> both positive and negative values) returns the convex hull of the two
> branches. But since the two branches return values separated by 2pi,
> the convex hull will be pessimally unsharp (at least 2pi wide, which
> for atan2() is effectively Entire).
IMO one should forget the case() function and do the theory from first principles. I'll use phase(x,y) = atan2(y,x) (= same as arg(x+iy)), which I find less confusing.
- If we have a box zz = (xx,yy) interior to Quadrant 3, say
zz =([-2,-1], [-1,-0.0001]),
then phase(zz) and our new phase_sharp(zz) both give an interval
say tt, contained in (at Level 1)
-pi < theta < -pi/2.
- If this box expands upwards a bit to intersect the branch-cut, e.g.
zz =([-2,-1], [-1,+0.0001]),
then the tt returned by phase_sharp(zz) doesn't change much in *width*
(unlike the old phase(), which now returns [-pi,pi], but it is suddenly
shifted up by 2pi to be contained in
pi < theta < 3pi/2.
Provided the 1788 text warns the user that this can happen, I don't see a problem. The decoration shall reflect the continuous function that was actually computed in either case. It's up to the user to make sense of the result.
If people have no objection to such a function, let's have a motion.
John Pryce