RfD: Ambiguity in FATAN2

RfD:  Ambiguity in FATAN2

Problem

The ANS definition is:

12.6.2.1489 FATAN2 
 f-a-tan-two FLOATING EXT     ( F: r1 r2 -- r3 ) or ( r1 r2 -- r3 ) 
 r3 is the radian angle whose tangent is r1/r2. An ambiguous condition 
exists if r1 and r2 are zero. 

This is incomplete, since it does not specify which of the countably 
infinite set of angles satisfying this specification will be returned as
r3.

Other computer languages which provide this function commonly specify the
"principal angle", the one between -pi and pi.

Proposal

The first sentence of the definition should be expanded to:
 r3 is the radian angle, greater than -pi and less than or equal to pi,
whose tangent is r1/r2.

Remarks

Discussions in comp.lang.forth have included general agreement that the
present definition is ambiguous, probably unintentionally, and that
specifying the principal angle would be the favored correction.

Experience

A summary quoted from a posting by David N. Williams in comp.lang.forth:

                      FATAN2 CONVENTIONS
   implementation    -pi to pi   0 to 2pi
   --------------------------------------
   pfe 0.33.70          yes         no
   gforth 0.7.0         yes         no
   kforth 1.4.0         yes         no
   iForth 3.0.3         yes         no
   4tH 3.5c             yes         no
   SwiftForth 3         no          yes
   VFX Forth  4         yes         no
   Win32Forth 6.13.00   yes         no

Testing

A set of tests is available at

 http://www.**--****.com/ ~williams/archive/forth/utilities/fatan2-test.fs

\ end of RfD

regards to all   cgm

"C. G. Montgomery" < XXXX@XXXXX.COM > writes:

The C standard specifies "[-pi,pi]", i.e., greater than or equal to
-pi.

And on Gforth (which uses C's atan2):
-1e 0e fatan2 f.

outputs

-1.5707963267949

and I guess that Gforth is not the only one.

So I suggest including -pi in the range.

- anton
-- 
M. Anton Ertl   http://www.**--****.com/ 
comp.lang.forth FAQs:  http://www.**--****.com/ 
     New standard:  http://www.**--****.com/ 

It can surely be either:

 atan ( +inf ) = pi, atan ( -inf ) = -pi

That's what the Pentiums do, and it would be a shame to have to put
special-case code around the intruction to be standard.

 http://www.**--****.com/ 

Andrew.

 > "C. G. Montgomery" < XXXX@XXXXX.COM > writes:
 >> Other computer languages which provide this function commonly 
specify the
 >> "principal angle", the one between -pi and pi.
 >>
 >> Proposal
 >>
 >> The first sentence of the definition should be expanded to:
 >> r3 is the radian angle, greater than -pi and less than or equal to pi,
 >> whose tangent is r1/r2.
 >
 > The C standard specifies "[-pi,pi]", i.e., greater than or equal to
 > -pi.

Right.  There's a discrepancy in that respect with OpenMath.  I vote
for the C spec, because it's natural when you have -0e, as in the
test

   \   y   x
   t{ -0e -1e fatan2 -> -pi }t

for which (x, y) = (-1e,-0e) expresses the limit from below on
the negative real axis.

 > And on Gforth (which uses C's atan2):
 > -1e 0e fatan2 f.
 >
 > outputs
 >
 > -1.5707963267949
 >
 > and I guess that Gforth is not the only one.

True, but I wonder if you didn't mean:

   -0e -1e fatan2 f. -3.14159265358979  ok

 > So I suggest including -pi in the range.

Me, too.  I believe the replacement language "greater than or
equal to -pi and less than or equal to pi" in Charles' proposal
would not mean that a compliant system actually has to have -0e,
with FATAN2 actually defined at the limit from below on the
negative real axis.

On the other hand, I would certainly hope that systems that do
have IEEE 754, which is optional in ANS Forth, would have -0e
and would give the -pi result above.

-- David

"David N. Williams" < XXXX@XXXXX.COM > writes:



Ah, yes, too many factors of 2 confused me:-) So my argument was
totally bogus.  Fortunately you found a better one that demonstrates
my point.

Cool:

-0e -1e fatan2 f. -3.14159265358979  ok
0e -1e fatan2 f. 3.14159265358979  ok


No, this just relaxes a restriction on the system (a little).  It does
not require the system to produce -pi, just like the current language
(which allows -pi) doesn't.

An argument for the "principal angle" is that it reduces the
truncation errors, especially for results that are close to 0 and
negative; with SwiftForth's method they would be close to 2pi.

An example is:

-1e-13 1e fatan2 fs. 1.00000000000000E-13

There are still 15 or so significant digits here.  After adding 2pi,
there are only 3 or so:

pi 2e f* -1e-13 1e fatan2 fover f+ fswap f- fs. -1.00364161426114E-13

- anton
-- 
M. Anton Ertl   http://www.**--****.com/ 
comp.lang.forth FAQs:  http://www.**--****.com/ 
     New standard:  http://www.**--****.com/ 

Yes, I was hoping to avoid extra problems related to whether a system
supported negative zeros.

One can't just include both -pi and pi in the specification.  That still
leaves an ambiguity.

To avoid system requirements but allow the preferred behavior with a
negative zero for systems that support it, perhaps one could add the
sentence:
A system for which -0E is distinct from 0E shall return a value
(approximating) -pi when r1=-0E and r2 is negative.

Or, in order to slightly ease the requirement on developers, "shall" could
be replaced with "may".  But in that case there should probably be a
requirement that such a system document which behavior it provides. 
Easier to just require it.

I'd be happy either way.

regards   cgm

But this is for FATAN2, not FATAN.

regards   cgm

"C. G. Montgomery" < XXXX@XXXXX.COM > writes:

If a program cannot rely on that behaviour (because -0e is not
required), it's pointless to require that behaviour from a subset of
systems; programs will still not be able to rely on it.  Concerning
"may", if you want to suggest some preferred behaviour, I guess you
could put it in some non-normative part (i.e., the rationale); the
normative part ist for requirements ("must" in English, "shall" in
Standardese) and guarentees ("does" or "does not").

- anton
-- 
M. Anton Ertl   http://www.**--****.com/ 
comp.lang.forth FAQs:  http://www.**--****.com/ 
     New standard:  http://www.**--****.com/ 

"The FPATAN instruction returns the angle between the X axis and the
line from the origin to the point (X,Y), where Y (the ordinate) is
ST(1) and X (the abscissa) is ST(0). The angle depends on the sign of
X and Y independently, not just on the sign of the ratio Y/X. This is
because a point (-X,Y) is in the second quadrant, resulting in an
angle between p/2 and p, while a point (X,-Y) is in the fourth
quadrant, resulting in an angle between 0 and -p/2. A point (-X,-Y) is
in the third quadrant, giving an angle between -p/2 and -p."

So

0.0e 0.e0 fatan2 f. 0.  ok
0.0e -0.e0 fatan2 f. 3.14159265358979  ok
-0.0e -0.e0 fatan2 f. -3.14159265358979  ok
-0.0e 0.e0 fatan2 f. -0.  ok

And, as I said, having to do something other than executing the
FPATAN2 instruction would be a Bad Thing.

Andrew.

Andrew Haley < XXXX@XXXXX.COM > writes Re: RfD:  Ambiguity in FATAN2
[..]


It's not.


They don't.

-marcel

-- ----------------------------------------------------------------
FORTH> +inf fatan pi/2             f- +e.  0.00000000000000e+000 ok
FORTH> -inf fatan pi/2   fnegate   f- +e.  0.00000000000000e+000 ok

I disagree with this.  A program that relies on the behavior of FATAN2
when the first argument is a negative zero needs to know, somehow or
other, whether it is running on a system which has a negative zero.
IMHO, a program that depends on what value FATAN2 returns for locations on
the negative-x axis without knowing whether negative zeros are supported
should be a non-standard program (perhaps with an environmental
dependency), rather than accepting that a standard system may return
either of two different values.

But as I indicated, I would be willing to have the ambiguity in the
definition retained PROVIDED there is a requirement that a system include
specification of its behavior in its documentation.  It just seems
simpler to handle the special case in the definition of the word.

regards   cgm

I quite agree.  I think that this is taken care of by the additional
requirement for systems with negative zeros, discussed elsewhere in this
thread.

regards   cgm

It does, yes.  The C standard allows for this with wordage like

"An implementation that defines __STDC_IEC_559_COMPLEX__ should
conform to the specifications in this annex."

So, by analogy, "An implementation that returns true in response to
the environmental query 'FLOATING-NEGATIVE-ZERO' shall return a value
(approximating) -pi when r1=-0E and r2 is negative."

Or something.  :-)

Andrew.

"C. G. Montgomery" < XXXX@XXXXX.COM > writes:



Yes.  If you want that, we either need to require a negative 0, or we
need to provide a way for a program to query for it (e.g., by making
it a Forth 200x extension and using an extension query); and you need
to put the refined behaviour of FATAN2 in that extension.


I don't see a contradition between the two clauses.  If it is not
defined how a standard system behaves in this case, a program relying
on a particular behaviour won't be standard (or, if it's documented as
such, it will have an environmental dependency), as you think it
should be.


IMO documentation requirements are not helpful.  They just cost work
and help in hardly any case; who has the time to sift through program
documentation and system documentation, and match up what may or may
not work?  And who knows if the documentation is correct anyway?
Better run some test on the system that tests for the behaviour you
need; write the test once, and you can run it on every system and
every new version of each system.

- anton
-- 
M. Anton Ertl   http://www.**--****.com/ 
comp.lang.forth FAQs:  http://www.**--****.com/ 
     New standard:  http://www.**--****.com/