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


Groups > comp.lang.forth > #50415

Re: fatan2 2012

From "HAA" <someone@microsoft.com>
Newsgroups comp.lang.forth
Subject Re: fatan2 2012
Date 2016-08-23 12:51 +1000
Organization Aioe.org NNTP Server
Message-ID <npgdmc$1pmf$1@gioia.aioe.org> (permalink)
References <npdse1$1s5g$1@gioia.aioe.org> <2016Aug22.120058@mips.complang.tuwien.ac.at>

Show all headers | View raw


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.


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