Re: Alternative atan2 (was Motion 52: final ...)
I was just thinking about why atan2() has this problem, but the other
inverse-trig functions don't. Wouldn't every periodic function have
a problem with defining its inverse?
It seems that the reason the other trig functions (sin, cos, even tan)
have a well-defined interval inverse (asin, acos, atan) is that the
ranges are defined such that the derivative is zero at the endpoints,
or that there is a pole there (tan), so that result can be sharply on
one side of the range endpoint -- except for a trespass of less than
one ulp due to outward rounding.
However, d(atan2(y,x))/dy when y is near zero is 1/x, which is nonzero.
In any case, if we want to include atan2_sharp(), we need to verify
that the FTIA is not affected. We also need to pay attention to the
definition of accuracy, in 12.10.1 -- because technically atan2_sharp()
is not even *valid* according to test (31).
I think what we need are three point functions, atan2(), atan2p() and
atan2m(), with respective ranges (-pi,+pi], [+pi,+3pi) and (-3pi,-pi],
with a rule that selects the appropriate one, based on which argument
contains zero (if any). I guess [-pi,+pi]_trv would be returned if
both arguments contain 0.
Actually, I'm confused now. I can't figure out how one would decide
between atan2p() and atan2m(): perhaps that choice would be fixed,
and we only need two point functions, atan2() and atan2p().
In fact, I think we need to define overlapping ranges, i.e. to define
atan2p() to have the range [0,+2pi). Would that work? My head is
spinning: too many years since I had to think about any of this.
Suggestions?
Michel.
---Sent: 2013-12-02 17:31:35 UTC