Front page | perl.perl5.porters |
Postings from January 2001
Re: [PATCH: perl@8342] lib/bigfloat.t FAILED at test 351
From:
Peter Prymmer
Date:
January 11, 2001 12:13
Subject:
Re: [PATCH: perl@8342] lib/bigfloat.t FAILED at test 351
Message ID:
Pine.OSF.4.10.10101111150240.405058-100000@aspara.forte.com
On Wed, 10 Jan 2001, Jarkko Hietaniemi wrote:
> 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.
I interpreted the patch as applying to lib/bigint.pl and
lib/Math/BigInt.pm, yet you refer to "tweaking test scripts". The patch
did not seem to mention any *.t file nor the t nor t/lib directories.
None the less switching C<($y * 1e-5) * 1e5> to C<($y / 1e5) * 1e5>
should be a performance hit on architectures whose fp division is
considerable slower than fp multiplication. Would you prefer that there
be new extracted versions of those lib files such as lib/bigint_pl.PL
and lib/Math/BigInt_pm.PL? That might look in part like:
use Config;
if ($Config{'fp_divide_broken'} eq 'define') {
print OUT '$prod - ($car = int($prod / 1e5)) * 1e5;';
}
else {
print OUT '$prod - ($car = int($prod * 1e-5)) * 1e5;';
}
or somesuch?
Peter Prymmer