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

Groups > comp.lang.forth > #50422

Re: fatan2 2012

Show all headers | View raw

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

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web