RfD: Ambiguity in FATAN2

forth

    Next

  • 1. history and rationale for CREATE vs. <BUILDS
    Does anyone know the history/reason behind the switch from <BUILDS DOES> to the CREATE DOES> form? What was it that suddenly allowed CREATE to replace <BUILDS? I suspect it could have something to do with threading mechanisms, but I could be wrong about that. Regards, -- Greg

RfD: Ambiguity in FATAN2

Postby C. G. Montgomery » Wed, 25 Mar 2009 11:43:05 GMT

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

Re: RfD: Ambiguity in FATAN2

Postby anton » Wed, 25 Mar 2009 19:41:23 GMT

"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/ 

Re: RfD: Ambiguity in FATAN2

Postby Andrew Haley » Wed, 25 Mar 2009 20:38:48 GMT




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.

Re: RfD: Ambiguity in FATAN2

Postby David N. Williams » Wed, 25 Mar 2009 21:35:18 GMT


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

Re: RfD: Ambiguity in FATAN2

Postby anton » Wed, 25 Mar 2009 22:18:46 GMT

"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/ 

Re: RfD: Ambiguity in FATAN2

Postby C. G. Montgomery » Thu, 26 Mar 2009 00:41:52 GMT






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



Re: RfD: Ambiguity in FATAN2

Postby C. G. Montgomery » Thu, 26 Mar 2009 00:42:25 GMT






But this is for FATAN2, not FATAN.

regards   cgm

Re: RfD: Ambiguity in FATAN2

Postby anton » Thu, 26 Mar 2009 00:51:42 GMT

"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/ 

Re: RfD: Ambiguity in FATAN2

Postby Andrew Haley » Thu, 26 Mar 2009 01:26:15 GMT









"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.

Re: RfD: Ambiguity in FATAN2

Postby mhx » Thu, 26 Mar 2009 03:11:29 GMT

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


Re: RfD: Ambiguity in FATAN2

Postby C. G. Montgomery » Thu, 26 Mar 2009 05:21:18 GMT




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


Re: RfD: Ambiguity in FATAN2

Postby C. G. Montgomery » Thu, 26 Mar 2009 05:26:42 GMT



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


Re: RfD: Ambiguity in FATAN2

Postby Andrew Haley » Thu, 26 Mar 2009 05:46:23 GMT








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.

Re: RfD: Ambiguity in FATAN2

Postby anton » Fri, 27 Mar 2009 07:48:53 GMT

"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/ 

Re: RfD: Ambiguity in FATAN2

Postby C. G. Montgomery » Fri, 27 Mar 2009 09:20:48 GMT

nton Ertl XXXX@XXXXX.COM wrote:


You closed your parenthesis too quickly. ;-) (and see below)
We certainly don't want to require a negative zero. It seems
unreasonable, though, to impose an extra burden on a system that already
provides one.


I didn't intend to imply that it would be impossible to have both an
ambiguous standard for the system and also make programs that use it
non-standard as well. But I'd rather not have both.

If the standard required systems with a negative zero to handle FATAN2
differently when that value is its first argument, that guarantees what
result is produced when FATAN is given arguments r1=-0, r2<0. It also
guarantees what results on a system without a negative zero when the
arguments are zero and a negative value.
It seems to me that in that case a program which passes as negative zero
to FATAN2 and relies on the answer being +pi would be a non-standard
program.

There would already be an easy test: just execute -0e -1e FATAN2 ;-)


I agree in preferring an unambiguous standard to a documentation
requirement covering the ambiguity.

best regards cgm


Similar Threads:

1.RfD: Ambiguity in FATAN2 version 1.2

2.RfD: Ambiguity in FATAN2

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

3.RfD: Ambiguity in FATAN2 version 1.1

4.Ambiguity in FATAN2

5.CfV: Ambiguity in FATAN2

6. printf format ambiguity

7. Ambiguity in semantics of assignments?

8. pragma import ambiguity



Return to forth

 

Who is online

Users browsing this forum: No registered users and 10 guest