ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> perl5-porters
perl5-porters
[PATCH] op/numconver.t
by Nicholas Clark other posts by this author
Jun 30 2001 10:49PM messages near this date
Re: New results with numconvert.t (UTS) | Re: [PATCH] op/numconver.t
This patch adds comments explaining the reasons behind the allowed exceptions,
removes the VMS-naughty print "not " if ...; construction,
and closes one class of falsely allowed exceptions.

If I got the last bit right then any new "nok"s are real problems that were
being brushed under the carpet, and no correct longdouble, 64bitint
platforms will notice.
[Crays will now fail test 208, IIRC, which they were incorrectly passing
before. I don't yet know where the problem with Crays is.]

Nicholas Clark

--- t/op/numconvert.t.orig	Fri Jan 12 05:49:38 2001
+++ t/op/numconvert.t	Sat Jun 30 15:29:00 2001
@@ -204,20 +204,40 @@
 	      print "# ok, as string ++ of max_uv is \"$max_uv_pp\", numeric is $max_uv_p1\n"
 	    } elsif ($opnames[$last] eq 'I' and $ans[1] eq "-1"
 		     and $ans[0] eq $max_uv_p1_as_iv) {
+              # Max UV plus 1 is NV. This NV may stringify in E notation.
+              # And the number of decimal digits shown in E notation will depend
+              # on the binary digits in the mantissa. And it may be that
+              # (say)  18446744073709551616 in E notation is truncated to
+              # (say) 1.8446744073709551e+19 (say) which gets converted back
+              # as    1.8446744073709551000e+19
+              # ie    18446744073709551000
+              # which isn't the integer we first had.
+              # But each step of conversion is correct. So it's not an error.
+              # (Only shows up for 64 bit UVs and NVs with 64 bit mantissas,
+              #  and on Crays (64 bit integers, 48 bit mantissas) IIRC)
 	      print "# ok, \"$max_uv_p1\" correctly converts to IV \"$max_uv_p1_as_iv\"\n";
 	    } elsif ($opnames[$last] eq 'U' and $ans[1] eq ~0
 		     and $ans[0] eq $max_uv_p1_as_uv) {
+              # as aboce
 	      print "# ok, \"$max_uv_p1\" correctly converts to UV \"$max_uv_p1_as_uv\"\n";
 	    } elsif (grep {/^N$/} @opnames[@{$curops[0]}]
-		     and $ans[0] == $ans[1] and $ans[0] <= ~0) {
+		     and $ans[0] == $ans[1] and $ans[0] <= ~0
+                     # First must be in E notation (ie not just digits) and
+                     # second must still be an integer.
+                     # I can't remember why there isn't symmetry in this
+                     # exception, ie why only the first ops are tested for 'N'
+                     and $ans[0] !~ /^-?\d+$/ and $ans[0] !~ /^-?\d+$/) {
 	      print "# ok, numerically equal - notation changed due to adding zero\n";
 	    } else {
 	      $nok++,
 	    }
 	  }
 	}
-	print "not " if $nok;
-	print "ok $test\n";
+        if ($nok) {
+          print "not ok $test\n";
+        } else {
+          print "ok $test\n";
+        }
 	#print $txt if $nok;
 	$test++;
       }
Thread:
Nicholas Clark
Jarkko Hietaniemi

Privacy Policy | Email Opt-out | Feedback | Syndication
© ActiveState Software Inc. All rights reserved