Front page | perl.perl5.porters |
Postings from January 2001
On Wed, Jan 10, 2001 at 03:48:28PM +0100, Roca, Ignasi wrote:
> As I can see perl in VMS fails like in POSIX-BC on test 351 of test-script
> lib/bigfloat.t
>
> In POSIX-BC the /390-Arithmetic-Floating-Point implementation has some
> imprecisse results that affects the C-Math functions.
> Here an example:
> #include <math.h>
>
> main()
> {
> double r,s,t;
>
> printf ("\n<<< r = 800000.0 * 1e-5 >>>\n");
> r = 800000.0 * 1e-5;
> t = modf (r,&s);
> printf("r=%e, s=%e, t=%e\n",r,s,t);
>
> printf ("\n<<< r = 800000.0 / 1e+5 >>>\n");
> r = 800000.0 / 1e+5;
> t = modf (r,&s);
> printf("r=%e, s=%e, t=%e\n",r,s,t);
> }
>
>
> The result in POSIX-BC as unexpected is the following:
> <<< r = 800000.0 * 1e-5 >>>
> r=8.000000e+00, s=7.000000e+00, t=1.000000e+00
>
> <<< r = 800000.0 / 1e+5 >>>
> r=8.000000e+00, s=8.000000e+00, t=0.000000e+00
I'm not certain whether tweaking test scripts like this in one
direction is wise. What if this breaks the test in some other
platform? Multiplying with small numbers / dividing with big numbers
is like throwing dice. In general, expecting something precise out of
floating point computations is like expecting marketing claims to be true.
I could consider a solution where these 'fragile' computations
are isolated into one or more subroutines and the choice whether
we do a multiply or divide is made in runtime when the script starts,
based on some test similar to the above test written in C.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Thread Previous
|
Thread Next