Front page | perl.vmsperl |
Postings from June 2002
At 2:03 AM +0100 6/8/02, Hugo van der Sanden wrote:
>I feel I must be missing something here, but do you not similarly
>blow up when supplied 1e-200?
I'm the one who's missing something. You are quite right. Even
after my previous patch:
mcr []miniperl -e "print 1e-38;"
1e-38
$ mcr []miniperl -e "print 1e-39;"
$ write sys$output f$message($status)
%SYSTEM-F-HPARITH, high performance arithmetic trap, Imask=!XL, Fmask=!XL, summary=!XB, PC=!XH, PS=!XL
So we've simply never accounted for the case of negative exponents.
This routine has no comments at all about its basic purpose, the
definition or allowed values of its arguments or return value, or the
algorithm that it implements. It has rather verbose comments about
exceptional cases by people like me who haven't quite understood the
whole thing. Anyone with the knowledge to cover the basics of
inputs, outputs, boundary conditions and such would have my thanks
for adding a few lines. I think I might be starting to get it but
can't be sure.
> I would have expected something more
>like:
>
>#if defined(VMS) && !defined(__IEEE_FP) && defined(NV_MAX_10_EXP)
> if ((log10(value) + exponent) >= (NV_MAX_10_EXP))
> return negative ? 0.0 : NV_MAX;
>#endif
Indeed. If I switch to that I then get:
$ mcr []miniperl -e "print 1e-39;"
0
So the following gets us to do the fake underflow as well as fake
overflow in the absence of IEEE math:
--- numeric.c;-1 Fri Jun 7 16:40:25 2002
+++ numeric.c Fri Jun 7 22:18:01 2002
@@ -744,9 +744,8 @@
* [1] Trying to establish a condition handler to trap floating point
* exceptions is not a good idea. */
#if defined(VMS) && !defined(__IEEE_FP) && defined(NV_MAX_10_EXP)
- if (!negative &&
- (log10(value) + exponent) >= (NV_MAX_10_EXP))
- return NV_MAX;
+ if ((log10(value) + exponent) >= (NV_MAX_10_EXP))
+ return negative ? 0.0 : NV_MAX;
#endif
/* In UNICOS and in certain Cray models (such as T90) there is no
[end of patch]
Someone with UNICOS access really ought to see whether the same thing
is necessary there, i.e., whether underflow as well as overflow needs to
be accounted for.
--
________________________________________
Craig A. Berry
mailto:craigberry@mac.com
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
Thread Next