Re: [PATCH] New test of IEEE floating point peculiarities
On Sat, Aug 06, 2005 at 04:58:53PM +0200, Dominic Dunlop wrote: Following on from perlbug #36676, which concerned perl's handling of a peculiarity of IEEE-standard floating point, I've attached a patch that creates a new test script, op/t/ieeefp.t: # ieeefp.t # # Tests IEEE floating-point peculiarites: infinity, not-a-number, negative # zero. Based on information from http://www.savrola.com/resources # with thanks. # # Not applicable to architectures where floating-point does not follow # the IEEE standard -- see the comment Add your architecture here ... The tests are intended to exercise the underlying floating point hardware and library support; I've tried to steer clear of stuff that's already tested in op/sprintf.t. This proved impossible for negative zero, and consequently there's a skip for certain architectures round some tests that require that negative zero is stringified as -0. (If somebody can point me at a user-visible way in Perl of extracting the sign from an NV other than by stringifying it, I'd love to hear about it.) And of course everything's skipped for non-IEEE floating point. The patch I just submitted to fix abs() (bug #36819) is a prerequisite. The patch does not update MANIFEST. Should it? The PERL_PRESERVE_IVUV stuff can lose a negative zero. $ perl -we'$x = -.0; $x *= 1.0; print $x' 0 $ perl -we'$x = -.0; $x *= 1.1; print $x' -0 Should a negative zero never get IOK turned on?
Re: [PATCH] New test of IEEE floating point peculiarities
On 2005–08–11, at 11:05, Yitzchak Scott-Thoennes wrote: The PERL_PRESERVE_IVUV stuff can lose a negative zero. $ perl -we'$x = -.0; $x *= 1.0; print $x' 0 $ perl -we'$x = -.0; $x *= 1.1; print $x' -0 Should a negative zero never get IOK turned on? Certainly not in the case above. In the general case, probably not either. I've no time for a while to attempt a fix. Interestingly, the NV's still there after the first example. But it's vulnerable: $ perl -MDevel::Peek -we '$x = -.0; $x *= 1.0;print Dump $x; print Dump $x*1.1; $x *= 1.1; print Dump $x' SV = PVNV(0x180fc78) at 0x180b63c REFCNT = 1 FLAGS = (IOK,pIOK) IV = 0 NV = -0 PV = 0 SV = NV(0x180e018) at 0x1801440 REFCNT = 1 FLAGS = (PADTMP,NOK,pNOK) NV = 0 SV = PVNV(0x180fc78) at 0x180b63c REFCNT = 1 FLAGS = (NOK,pNOK) IV = 0 NV = 0 PV = 0 -- Dominic Dunlop
Re: [PATCH] New test of IEEE floating point peculiarities
On Thu, Aug 11, 2005 at 02:05:20AM -0700, Yitzchak Scott-Thoennes wrote: The PERL_PRESERVE_IVUV stuff can lose a negative zero. $ perl -we'$x = -.0; $x *= 1.0; print $x' 0 $ perl -we'$x = -.0; $x *= 1.1; print $x' -0 Should a negative zero never get IOK turned on? I meant to show the non-assignment case, where the - is a driveby shooting victim: $ perl -we'$x = -.0; scalar($x * 1.0); print $x' 0 $ perl -we'$x = -.0; scalar($x * 1.1); print $x' -0
Re: [PATCH] New test of IEEE floating point peculiarities
On Thu, Aug 11, 2005 at 03:31:11AM -0700, Yitzchak Scott-Thoennes wrote: On Thu, Aug 11, 2005 at 02:05:20AM -0700, Yitzchak Scott-Thoennes wrote: The PERL_PRESERVE_IVUV stuff can lose a negative zero. $ perl -we'$x = -.0; $x *= 1.0; print $x' 0 $ perl -we'$x = -.0; $x *= 1.1; print $x' -0 Should a negative zero never get IOK turned on? I meant to show the non-assignment case, where the - is a driveby shooting victim: $ perl -we'$x = -.0; scalar($x * 1.0); print $x' 0 $ perl -we'$x = -.0; scalar($x * 1.1); print $x' -0 Even worse: $ perl -we'$x = -.0; scalar(1.1 * $x); print $x' 0
Re: [PATCH] New test of IEEE floating point peculiarities
On Thu, Aug 11, 2005 at 03:57:27AM -0700, Yitzchak Scott-Thoennes wrote: Even worse: $ perl -we'$x = -.0; scalar(1.1 * $x); print $x' 0 'scuse my ignorance, but why is it important to preserve the sign on floating zeroes? -- A walk of a thousand miles begins with a single step... then continues for another 1,999,999 or so.
Re: [PATCH] New test of IEEE floating point peculiarities
On Thu, 11 Aug 2005 12:51:57 +0100, Dave Mitchell [EMAIL PROTECTED] wrote: On Thu, Aug 11, 2005 at 03:57:27AM -0700, Yitzchak Scott-Thoennes wrote: Even worse: $ perl -we'$x = -.0; scalar(1.1 * $x); print $x' 0 'scuse my ignorance, but why is it important to preserve the sign on floating zeroes? ANSI C90 says so IIRC -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using Perl 5.6.2, 5.8.0, 5.8.5, 5.9.2 on HP-UX 10.20, 11.00 11.11, AIX 4.3 5.2, SuSE 9.2 9.3, and Cygwin. http://www.cmve.net/~merijn Smoking perl: http://www.test-smoke.org,perl QA: http://qa.perl.org reports to: [EMAIL PROTECTED],perl-qa@perl.org
Re: [PATCH] New test of IEEE floating point peculiarities
On 2005–08–11, at 13:51, Dave Mitchell wrote: 'scuse my ignorance, but why is it important to preserve the sign on floating zeroes? On a scale of ten, its importance might crawl as high as a two. I think it's mainly there so that, when something gets rounded to zero, you can tell what side of zero it got rounded from. This might be useful in numerical analysis -- the example of atan2 given by Ton Hospel shows a function that will give the right answer for an input so small it's been rounded to zero, provided the sign of the zero is preserved. Not that I have any reason to believe that Perl is heavily used in numerical analysis -- if it were, somebody might have complained about the lack of support for subnormals, and nobody has. But given that negative zero's a part of IEEE 754 (or so I'm told -- the IEEE wants $42 for the standard, and I'm not going to shell out) it seems unfeeling of perl to stamp on it if the underlying hardware supports it. -- Dominic Dunlop
Re: [PATCH] New test of IEEE floating point peculiarities
On 2005–08–09, at 19:32, Ton Hospel wrote: atan2(X, -1) should do the job of mapping X to something with an easily testable sign Thanks. Works for me, but it's probably as much a test of the atan2 implementation as it is of -0.0. Looking at the bit pattern of the floating point representation as suggested by Piotr Fusik feels tackier, but is probably more reliable. Once xieeefp.t has given Inf, NaN and -0 a good thrashing, there is an argument for checking that mathematical functions behave correctly when fed them. But I'm not going to do that just now. (xieeefp.t does test sqrt(+/-Inf), but my excuse for including that is that it should go straight down to the metal these days.) For much on this kind of stuff, see http://www.cs.berkeley.edu/ ~wkahan/ieee754status/IEEE754.PDF -- not that I follow it all ... -- Dominic Dunlop
Re: [PATCH] New test of IEEE floating point peculiarities
In article [EMAIL PROTECTED], Dominic Dunlop [EMAIL PROTECTED] writes: stringified as -0. (If somebody can point me at a user-visible way in Perl of extracting the sign from an NV other than by stringifying it, I'd love to hear about it.) And of course everything's skipped atan2(X, -1) should do the job of mapping X to something with an easily testable sign perl -wle 'print atan2(-0.0, -1)' -3.14159265358979324 perl -wle 'print atan2(0.0, -1)' 3.14159265358979324
Re: [PATCH] Re: [PATCH] New test of IEEE floating point peculiarities
On 2005–08–07, at 20:20, Piotr Fusik wrote:
How about adding some tests for subnormals?
No point, unless they are a TODO. I'd prefer my patch to stand as it is.
Do you think it makes any sense?
Not at the moment. AFAICT, perl fumbles subnormals. I've attached a
(possibly byte-order dependent) C test program that tells me that my
system does handle them. It produces (less annotations)
Decimal Bit pattern
--- ---
0: 00
-0: 0x8000
1: 0x3ff0
-1: 0xbff0
1.5: 0x3ff8
-1.5: 0xbff8
nan: 0x7ff8
inf: 0x7ff0
-inf: 0xfff0
4.45015e-308: 0x001f
2.22507e-308: 0x0010 - Smallest normal
2.22507e-308: 0x000f - Largest subnormal
1.11254e-308: 0x0007
8.28905e-317: 0x00ff
4.94066e-324: 0x0001 - Smallest subnormal
Also attached is a fairly equivalent (and also byte-order dependent)
Perl script (modulo rounding). It produces:
0: 0x
-0: 0x8000
1: 0x3ff0
-1: 0xbff0
1.5: 0x3ff8
-1.5: 0xbff8
nan: 0x7ff8
inf: 0x7ff0
-inf: 0xfff0
4e-308: 0x001cc359e067a344
2e-308: 0x000e61acf033d1a2
1e-308: 0x000730d67819e8d1
0: 0x
0: 0x
0: 0x
For a positive subnormal value, the top three nybles are zero. Perl
gets a start on producing subnormal values, but quickly gives up.
There are also fewer significant digits in the decimal
representations than probably there should be.
If you want to raise perl's poor showing on subnormals as a bug, be
my guest.
--
Dominic Dunlop
main.c
Description: Binary data
#!perl -w
my @vals = (
0.0,
-0.0,
1.0,
-1.0,
1.5,
-1.5,
(1e200 * 1e200)/(1e200 * 1e200),
1e200 * 1e200,
-1e200 * 1e200,
4.45015e-308,
2.22507e-308,
1.11254e-308,
5.56268e-309,
8.28905e-317,
4.94066e-324);
printf(%12g: 0x%s\n, $_, unpack('H*', pack('F', $_))) for @vals;
__END__
Re: [PATCH] New test of IEEE floating point peculiarities
On 2005–08–06, at 20:25, Piotr Fusik wrote: On Windows: perl -le print unpack'H*',pack'F',-0.0 0080 On big-endians it will probably be: 8000 Indeed it is. Thanks. I'll look into that. If I can use it, I'll resubmit the patch with the new test script renamed so that it gets run after op/pack.t. -- Dominic Dunlop
[PATCH] Re: [PATCH] New test of IEEE floating point peculiarities
On 2005–08–06, at 20:25, Piotr Fusik wrote: (If somebody can point me at a user-visible way in Perl of extracting the sign from an NV other than by stringifying it, I'd love to hear about it.) On Windows: perl -le print unpack'H*',pack'F',-0.0 0080 On big-endians it will probably be: 8000 OK. Attached is a replacement patch which peeps at the sign bit as Piotr suggests. It _should_ work on little-endian systems as well as big-endian, but somebody else will have to test that. I also took the opportunity to add unicos and unicosmk (whatever that is) to the list of non-IEEE fp systems. Are there any more out there besides the VAX and IBM mainframes? Is anybody still supporting Tandem non-stop UX, for example? Note that the test script is now named xieeefp.t so that is gets run after pack.t. -- Dominic Dunlop xieeefp-patch Description: Binary data
Re: [PATCH] Re: [PATCH] New test of IEEE floating point peculiarities
How about adding some tests for subnormals? Do you think it makes any sense?
[PATCH] New test of IEEE floating point peculiarities
Following on from perlbug #36676, which concerned perl's handling of a peculiarity of IEEE-standard floating point, I've attached a patch that creates a new test script, op/t/ieeefp.t: # ieeefp.t # # Tests IEEE floating-point peculiarites: infinity, not-a-number, negative # zero. Based on information from http://www.savrola.com/resources # with thanks. # # Not applicable to architectures where floating-point does not follow # the IEEE standard -- see the comment Add your architecture here ... The tests are intended to exercise the underlying floating point hardware and library support; I've tried to steer clear of stuff that's already tested in op/sprintf.t. This proved impossible for negative zero, and consequently there's a skip for certain architectures round some tests that require that negative zero is stringified as -0. (If somebody can point me at a user-visible way in Perl of extracting the sign from an NV other than by stringifying it, I'd love to hear about it.) And of course everything's skipped for non-IEEE floating point. The patch I just submitted to fix abs() (bug #36819) is a prerequisite. The patch does not update MANIFEST. Should it? -- Dominic Dunlop ieeefp-patch Description: Binary data
Re: [PATCH] New test of IEEE floating point peculiarities
(If somebody can point me at a user-visible way in Perl of extracting the sign from an NV other than by stringifying it, I'd love to hear about it.) On Windows: perl -le print unpack'H*',pack'F',-0.0 0080 On big-endians it will probably be: 8000
