Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #50415
| 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> |
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
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