## RfD: Ambiguity in FATAN2 version 1.2

forth

### Next

• 1. Forth books on eBay
I hope this post doesn't offend anyone, but if anyone is in need of reference books, I've put 13 books up for sale as a group on eBay. I'm not trying to get rich, just trying to get them to someone else interested in Forth. :-) Doug

### RfD: Ambiguity in FATAN2 version 1.2

```RfD:  Ambiguity in FATAN2  version 1.2

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 principal radian angle (between -pi and pi)
whose tangent is r1/r2.
A system which returns FALSE for -0E 0E 0E F~ shall return a value
(approximating) -pi when r1=-0E and r2 is negative.

Remarks

This rewording follows the suggestion by Peter Knaggs that the language
follow the pattern used in the definition of FACOS, FASIN, and FATAN (but
with an added clarification of the term "principal").

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.

The second sentence calls for behavior similar to other languages, such as
C and Fortran, is consistent with much modern hardware, and its omission
would impose an unnecessary burden on system providers, since most
systems supporting negative zero follow IEEE floating point behavior
which behaves this way.

The wording of the second sentence has been chosen to be unambiguous
without the need for any new environmental query (even if F~ does not
behave properly).
cover support for negative zeros or perhaps general IEEE floating point
behavior.  If such extensions become accepted and provide an
environmental query that would be useful for specifying the behavior of
FATAN2, it would be very easy to make (yet another) modification to the
specification of FATAN2, to make use of them.

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
```

### Re: RfD: Ambiguity in FATAN2 version 1.2

```
...
...
...
Wow. This is a clever way to specify the behavior of FATAN2 without
conditionals. The above specification guarantees that the IEEE FP
compatible result with respect to -0E will be given by FATAN2 when a
Forth system has all of the following attributes:

1) The Forth system supports floating point signed zero.

2) The number interpreter recognizes "-0E" correctly, and sets the

3) F~ behaves correctly for exact matching.

Yet the specification does not require the system to comply with any
of the three attributes. Beautiful. This spec. side steps the issues
raised during the development of the FTRUNC Rfd.

Krishna

```

```On Mar 24, 10:41m,  XXXX@XXXXX.COM  (Anton Ertl)
wrote:
> "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.
>
> 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.
>

W32F gives the same (assuming the precision is set to 14). Since pi
cannot be represented exactly shouldn't it be the closest
approximations of pi and -pi, allowing for rounding).

> So I suggest including -pi in the range.
>
> - anton

George Hubert
```