Re: atan2_sharp() -- a Motion?
On Tue, Feb 11, 2014 at 12:17 PM, Jürgen Wolff von Gudenberg
<wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> 9John, Michel, P1788
> I support the idea to change the atan2 function.
> I propose to change the semantics of current atan2 to one of those
> mentioned by John below and to drop the old meaning as atan(yy/xx)
> old atan2(yy,xx) = {atan(y/x) | xin xx, y in yy}
> atan2_sharp not defined
> new atan2-sharp defined below can now be noted as atan2(yy,xx) because
> atan(yy/xx) is nearly the same (?)
No. In many environments the classic atan2() (let's call it
atan2_blunt()) has a strictly defined range of outputs, all of which
lie within tau/2 of the rotational origin. In some cases there are
national and international standards that require that constraint.
Nearly the same .NE. the same.
Changing the output range _requires_ that the name be changed.
Providing atan2_sharp(), which is both the narrowest result and the
least angle from the rotational origin, is not hard. Nor is providing
atan2_blunt(), which _always_ meets the standard regardless of
interval width difficult.
IMHO there is no reason to prefer one over the other unless there is a
constraint imposed by an authority higher than IEEE-1788 will ever
have. So we should provide _at_least_ functions named atan2() and
atan2_sharp(). For symmetry reasons we should also provide
atan2_blunt() as a synonym of the standard, classic atan2()
I you look in the proposal for adding IA to the C++ language you will
find an adulterated form of fmod() because the adulterated form is
supposedly gooder than the original. This is the path to madness.
> Am 10.02.2014 14:14, schrieb John Pryce:
> We further may include the function atan2toPair which returns the 2 separate
> parts, the exact solution set
Now here we have the "right" solution because it is essentially
impossible for a sane user to apply the function inappropriately. But
I prefer the name atan2_pair() because the "to" in the name mentioned
above suggests that it denotes a conversion function rather than a
calculation function. Denotation is the only thing of interest to the
true mathematician. But connotation is what will matter to users of
IEEE-1788 hardware and software.
We are already afflicted by inf. Let us not multiply the
multiply-defined entities.
Lee Winter
Nashua, New Hampshire
United States of America