Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #50378 > unrolled thread

fatan2 2012

Back to article view | Back to comp.lang.forth

Contents

  fatan2 2012 "HAA" <someone@microsoft.com> - 2016-08-22 13:44 +1000
    Re: fatan2 2012 Paul Rubin <no.email@nospam.invalid> - 2016-08-21 21:01 -0700
    Re: fatan2 2012 peter.m.falth@gmail.com - 2016-08-22 00:42 -0700
    Re: fatan2 2012 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-22 10:00 +0000
      Re: fatan2 2012 "HAA" <someone@microsoft.com> - 2016-08-23 12:51 +1000
        Re: fatan2 2012 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-23 11:11 +0000
          Re: fatan2 2012 "HAA" <someone@microsoft.com> - 2016-08-25 02:16 +1000
          Re: fatan2 2012 albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-02 18:03 +0200
            Re: fatan2 2012 Paul Rubin <no.email@nospam.invalid> - 2016-09-02 12:02 -0700

#50378 — fatan2 2012

From the PDF ...

12.6.2.1489 FATAN2 "f-a-tan-two" FLOATING EXT
( F: r1 r2 -- r3 ) or ( r1 r2 -- r3 )
r3 is the principal radian angle (between -pi and pi ) whose tangent is r1 / r2 .
A system that returns false for "-0E 0E 0E F~" shall return a value (approximating) -pi
when r1 = 0E and r2 is negative.

Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
-0e 0e 0e f~ . 0  ok
0e -1e fatan2 fs. 3.14159265358979E0  ok

Same for Win32Forth

What should I do now?

I assume there is an error in the test as supplied.

BTW there several 'corner case' tests that could be applied to FATAN2.
Singling out one with no explanation is only going to leave readers with
questions when it does fail i.e. what's so special about *this* test.
Then there is the reliance on the notorious F~ whose results can be
right or wrong depending upon your expectations e.g.

SwiftForth i386-Win32 3.6.2 04-Apr-2016

0e pad f! pad 1 floats dump
  4809E8 00 00 00 00 00 00 00 00                         ........         ok
0e fnegate pad f! pad 1 floats dump
  4809E8 00 00 00 00 00 00 00 80                         ........         ok

0e fdup fnegate 0e f~ . -1  ok

0e fs. 0.0000000E+00  ok
0e fnegate fs. 0.0000000E+00  ok

[toc] | [next] | [standalone]

#50379

"HAA" <someone@microsoft.com> writes:
> -0e 0e 0e f~ . 0  ok
> 0e -1e fatan2 fs. 3.14159265358979E0  ok

Looks like fatan2 is right and f~ is wrong.

> Then there is the reliance on the notorious F~ whose results can be
> right or wrong depending upon your expectations e.g.

64-bit gforth 0.7.0:

    fvariable a  ok
    fvariable b  ok
    -0e a f!  ok
    0e b f!  ok
    a f@ b f@ f= . -1  ok

    -0e f. -0.  ok
    a @ b @ .s <2> -9223372036854775808 0  ok

0 and -0 obviously have different bit patterns.

[toc] | [prev] | [next] | [standalone]

#50397

On Monday, 22 August 2016 05:44:04 UTC+2, HAA  wrote:
> From the PDF ...
> 
> 12.6.2.1489 FATAN2 "f-a-tan-two" FLOATING EXT
> ( F: r1 r2 -- r3 ) or ( r1 r2 -- r3 )
> r3 is the principal radian angle (between -pi and pi ) whose tangent is r1 / r2 .
> A system that returns false for "-0E 0E 0E F~" shall return a value (approximating) -pi
> when r1 = 0E and r2 is negative.
> 
> Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
> Type `bye' to exit
> -0e 0e 0e f~ . 0  ok
> 0e -1e fatan2 fs. 3.14159265358979E0  ok
> 
> Same for Win32Forth
> 
> What should I do now?
> 

Looking at this and my implementation I think the standard is wrong
and is missing a -

should it not be -0E and r2 is negative returns pi?

I use fdlibm53 in my implementation
here are the special cases it gives

Special cases:
 *
 *	ATAN2((anything), NaN ) is NaN;
 *	ATAN2(NAN , (anything) ) is NaN;
 *	ATAN2(+-0, +(anything but NaN)) is +-0  ;
 *	ATAN2(+-0, -(anything but NaN)) is +-pi ;
 *	ATAN2(+-(anything but 0 and NaN), 0) is +-pi/2;
 *	ATAN2(+-(anything but INF and NaN), +INF) is +-0 ;
 *	ATAN2(+-(anything but INF and NaN), -INF) is +-pi;
 *	ATAN2(+-INF,+INF ) is +-pi/4 ;
 *	ATAN2(+-INF,-INF ) is +-3pi/4;
 *	ATAN2(+-INF, (anything but,0,NaN, and INF)) is +-pi/2; 

BR
Peter Fälth



> I assume there is an error in the test as supplied.
> 
> BTW there several 'corner case' tests that could be applied to FATAN2.
> Singling out one with no explanation is only going to leave readers with
> questions when it does fail i.e. what's so special about *this* test.
> Then there is the reliance on the notorious F~ whose results can be
> right or wrong depending upon your expectations e.g.
> 
> SwiftForth i386-Win32 3.6.2 04-Apr-2016
> 
> 0e pad f! pad 1 floats dump
>   4809E8 00 00 00 00 00 00 00 00                         ........         ok
> 0e fnegate pad f! pad 1 floats dump
>   4809E8 00 00 00 00 00 00 00 80                         ........         ok
> 
> 0e fdup fnegate 0e f~ . -1  ok
> 
> 0e fs. 0.0000000E+00  ok
> 0e fnegate fs. 0.0000000E+00  ok

[toc] | [prev] | [next] | [standalone]

#50401

"HAA" <someone@microsoft.com> writes:
>From the PDF ...
>
>12.6.2.1489 FATAN2 "f-a-tan-two" FLOATING EXT
>( F: r1 r2 -- r3 ) or ( r1 r2 -- r3 )
>r3 is the principal radian angle (between -pi and pi ) whose tangent is r1 / r2 .
>A system that returns false for "-0E 0E 0E F~" shall return a value (approximating) -pi
>when r1 = 0E and r2 is negative.
>
>Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
>Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
>Type `bye' to exit
>-0e 0e 0e f~ . 0  ok
>0e -1e fatan2 fs. 3.14159265358979E0  ok
>
>Same for Win32Forth
>
>What should I do now?
>
>I assume there is an error in the test as supplied.

Looking at the proposal <http://www.forth200x.org/fatan2.html>, the
proposed wording is:

|A system which returns FALSE for -0E 0E 0E F~ shall return a value
|(approximating) -pi when r1=-0E and r2 is negative.

The proposal contains tests

\ If y is +/-0 and x is < 0, +/-pi shall be returned.
t{  0e -1e fatan2 ->  pi }t
t{ -0e -1e fatan2 -> -pi }t

and the standard contains the same tests:

 \ If y is +/-0 and x is < 0, +/-pi shall be returned.
T{  0e -1e FATAN2 ->  pi R}T
T{ -0e -1e FATAN2 -> -pi R}T 

My guess is that the "r1 = 0E" instead of "r1 = -0e" in the standard
is an editorial mistake.  Thank you for pointing it out.

>BTW there several 'corner case' tests that could be applied to FATAN2.
>Singling out one with no explanation is only going to leave readers with
>questions when it does fail i.e. what's so special about *this* test.

This is a specification, not a test case.  There are many more test
cases in the proposal <http://www.forth200x.org/tests/fatan2.fs> and
the standard <http://forth-standard.org/standard/float/FATANTwo>.
This is one of four cases where there can be two possible results.
Why not the other cases?  The proposal does not say, and from what I
remember, nobody asked during the RfD phase.

The proposal contains the following explanation for the second
sentence of the specification:

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

>Then there is the reliance on the notorious F~ whose results can be
>right or wrong depending upon your expectations e.g.
>
>SwiftForth i386-Win32 3.6.2 04-Apr-2016
>
>0e pad f! pad 1 floats dump
>  4809E8 00 00 00 00 00 00 00 00                         ........         ok
>0e fnegate pad f! pad 1 floats dump
>  4809E8 00 00 00 00 00 00 00 80                         ........         ok
>
>0e fdup fnegate 0e f~ . -1  ok

Looks like a bug in SwiftForth's F~ to me.

But apart from that, I did not know that F~ is notorious, even though
it is a Frankenstein-like moster, probably grown out of the desire to
keep the word count small at all costs.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#50415

Anton Ertl wrote:
> ...
> My guess is that the "r1 = 0E" instead of "r1 = -0e" in the standard
> is an editorial mistake.  Thank you for pointing it out.
>
> >BTW there several 'corner case' tests that could be applied to FATAN2.
> >Singling out one with no explanation is only going to leave readers with
> >questions when it does fail i.e. what's so special about *this* test.
>
> This is a specification, not a test case.

Then it would appear to be a redundant specification.  The only possible way
to obtain a result approaching -pi is when both inputs (y,x) are negative.
The extra sentence adds nothing we didn't already know or could reasonably
deduce.  What other language has this 'specification' tacked on?

> The proposal contains the following explanation for the second
> sentence of the specification:
>
> |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.

I'm puzzled what that burden might be.  Systems that don't support -ve zero
have never been required to.  For systems that do, the correct result was
never in doubt.

> >SwiftForth i386-Win32 3.6.2 04-Apr-2016
> >
> >0e pad f! pad 1 floats dump
> >  4809E8 00 00 00 00 00 00 00 00                         ........         ok
> >0e fnegate pad f! pad 1 floats dump
> >  4809E8 00 00 00 00 00 00 00 80                         ........         ok
> >
> >0e fdup fnegate 0e f~ . -1  ok
>
> Looks like a bug in SwiftForth's F~ to me.

That's what's notorious about F~ not everyone agrees.
As demonstrated SwitfForth produces the following

> 0e fs. 0.0000000E+00  ok
> 0e fnegate fs. 0.0000000E+00  ok

If a system cannot *display* -ve zero then for all practical purposes it doesn't
exist, irrespective of the capabilities of the underlying hardware.  As far as the
SwitfForth end-user is concerned the "encodings" produce the same result
in every situation and therefore F~ should return a match.

[toc] | [prev] | [next] | [standalone]

#50422

"HAA" <someone@microsoft.com> writes:
>Anton Ertl wrote:
>> ...
>> My guess is that the "r1 = 0E" instead of "r1 = -0e" in the standard
>> is an editorial mistake.  Thank you for pointing it out.
>>
>> >BTW there several 'corner case' tests that could be applied to FATAN2.
>> >Singling out one with no explanation is only going to leave readers with
>> >questions when it does fail i.e. what's so special about *this* test.
>>
>> This is a specification, not a test case.
>
>Then it would appear to be a redundant specification.

pi and -pi both represent the same direction, and are within the range
of the function, so no, specifying which of the two is returned is not
redundant.

>  The only possible way
>to obtain a result approaching -pi is when both inputs (y,x) are negative.
>The extra sentence adds nothing we didn't already know or could reasonably
>deduce.  What other language has this 'specification' tacked on?

SUS v4/POSIX 2013 says for atan2():

|If y is +/-0 and x is < 0, +/-pi shall be returned.

(plus other specific cases).  I think that the order of the +/- is
significant, but am too lazy to look it up.

The Linux man-page on atan2() says:

|If y is +0 (-0) and x is less than 0, +pi (-pi) is returned.

(plus other specific cases) Here it is pretty clear that the +0
corresponds to +pi, and the -0 to -pi.

I wonder why the RfD on FATAN2 only specified this case, and not the
others that can give pi or -pi.  And whether any program actually
relies on this case giving -pi instead of pi, and why.

>> The proposal contains the following explanation for the second
>> sentence of the specification:
>>
>> |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.
>
>I'm puzzled what that burden might be.

Maybe the proponent wanted to (but did not) specify that the result r
is in the range -pi<r<=+pi, and wanted to make this an exception to
that statement; in that case another exception is y<0, x=-inf (also
returns -pi according to the Linux manpages and POSIX).

>> >SwiftForth i386-Win32 3.6.2 04-Apr-2016
>> >
>> >0e pad f! pad 1 floats dump
>> >  4809E8 00 00 00 00 00 00 00 00                         ........         ok
>> >0e fnegate pad f! pad 1 floats dump
>> >  4809E8 00 00 00 00 00 00 00 80                         ........         ok
>> >
>> >0e fdup fnegate 0e f~ . -1  ok
>>
>> Looks like a bug in SwiftForth's F~ to me.
>
>That's what's notorious about F~ not everyone agrees.

Have you reported a bug to Forth, Inc., and they disagreed?

>As demonstrated SwitfForth produces the following
>
>> 0e fs. 0.0000000E+00  ok
>> 0e fnegate fs. 0.0000000E+00  ok

So?  I don't think that there is a requirement for FS. or other
FP-printing words to output a minus sign when printing a negative 0.

>If a system cannot *display* -ve zero then for all practical purposes it doesn't
>exist, irrespective of the capabilities of the underlying hardware.  As far as the
>SwitfForth end-user is concerned the "encodings" produce the same result
>in every situation and therefore F~ should return a match.

Except that the specification of F~ specifically refers to the bit
pattern, and, as you demonstrate, the bit pattern is different, and
you also demonstrated that a user can determine this.

But indeed, running a few tests, it seems that the FP part of
SwiftForth mostly behaves as if it did not have a -0.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#50447

Anton Ertl wrote:
> "HAA" <someone@microsoft.com> writes:
> >Anton Ertl wrote:
> >> ...
> >> This is a specification, not a test case.
> >
> >Then it would appear to be a redundant specification.
>
> pi and -pi both represent the same direction, and are within the range
> of the function, so no, specifying which of the two is returned is not
> redundant.

A +ve value for y specifies the 1st or 2nd quadrant.  The result cannot
be anything but +ve.

A -ve value for y specifies the 3rd or 4th quadrant.  The result cannot
be anything but -ve.

The extra specification is redundant.

> >> >SwiftForth i386-Win32 3.6.2 04-Apr-2016
> >> >
> >> >0e pad f! pad 1 floats dump
> >> >  4809E8 00 00 00 00 00 00 00 00                         ........         ok
> >> >0e fnegate pad f! pad 1 floats dump
> >> >  4809E8 00 00 00 00 00 00 00 80                         ........         ok
> >> >
> >> >0e fdup fnegate 0e f~ . -1  ok
> >>
> >> Looks like a bug in SwiftForth's F~ to me.
> >
> >That's what's notorious about F~ not everyone agrees.
>
> Have you reported a bug to Forth, Inc., and they disagreed?

I didn't claim they had a bug.

> >As demonstrated SwitfForth produces the following
> >
> >> 0e fs. 0.0000000E+00  ok
> >> 0e fnegate fs. 0.0000000E+00  ok
>
> So?  I don't think that there is a requirement for FS. or other
> FP-printing words to output a minus sign when printing a negative 0.

SWF does not claim to support -ve zero.

> >If a system cannot *display* -ve zero then for all practical purposes it doesn't
> >exist, irrespective of the capabilities of the underlying hardware.  As far as the
> >SwitfForth end-user is concerned the "encodings" produce the same result
> >in every situation and therefore F~ should return a match.
>
> Except that the specification of F~ specifically refers to the bit
> pattern,

F~ refers to 'different encodings' for +0e and -0e for systems that
support these two.  SWF F/P only supports one.

[toc] | [prev] | [next] | [standalone]

#50621

In article <2016Aug23.131107@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>"HAA" <someone@microsoft.com> writes:
>>Anton Ertl wrote:
>>> ...
>>> My guess is that the "r1 = 0E" instead of "r1 = -0e" in the standard
>>> is an editorial mistake.  Thank you for pointing it out.
>>>
>>> >BTW there several 'corner case' tests that could be applied to FATAN2.
>>> >Singling out one with no explanation is only going to leave readers with
>>> >questions when it does fail i.e. what's so special about *this* test.
>>>
>>> This is a specification, not a test case.
>>
>>Then it would appear to be a redundant specification.
>
>pi and -pi both represent the same direction, and are within the range
>of the function, so no, specifying which of the two is returned is not
>redundant.
>
>>  The only possible way
>>to obtain a result approaching -pi is when both inputs (y,x) are negative.
>>The extra sentence adds nothing we didn't already know or could reasonably
>>deduce.  What other language has this 'specification' tacked on?
>
>SUS v4/POSIX 2013 says for atan2():
>
>|If y is +/-0 and x is < 0, +/-pi shall be returned.
>
>(plus other specific cases).  I think that the order of the +/- is
>significant, but am too lazy to look it up.

It looks like a bug-compatibility with a stone-age mainframe.
Furthermore it cannot be fullfilled because pi has no
representation in the fp set of computers (!).
A reasonable requirement would seem:
    Introduce PI~ : a value that is a roundup from mathematical pi to
    an fp representation, machine dependant.
    Then require the result to be in the range
     (-PI~, PI~]

This however is not satisfactory either.
I would not want to rule out a poor mans Forth where the FATAN2
returns a couple of machine precisions above the mathematical pi here
and there.
fp is a can of worms.

>
>- anton
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#50627

albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>>|If y is +/-0 and x is < 0, +/-pi shall be returned.
>>(plus other specific cases).  I think that the order of the +/- is
>>significant, but am too lazy to look it up.
> It looks like a bug-compatibility with a stone-age mainframe.
> Furthermore it cannot be fullfilled because pi has no
> representation in the fp set of computers (!).

It looks more like a specification of the right thing to do with the
signs, than one saying pi's representation must be exact.  And it's
probably inspired by IEEE754 or something similar, which put some effort
into getting branch cuts consistent.  Old mainframes often got that
wrong.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web