Front page | perl.perl5.porters |
Postings from January 2001
Re: [PATCH: perl@8342] lib/bigfloat.t FAILED at test 351
From:
John Peacock
Date:
January 11, 2001 12:37
Subject:
Re: [PATCH: perl@8342] lib/bigfloat.t FAILED at test 351
Message ID:
3A5E1986.40E603DD@rowman.com
Jarkko, Peter, et al -
This whole discussion begs the question that perhaps BigInt.pm needs
a complete overhaul, preferentially as a thin layer over a fast integer
math lib (when possible). I am an interested party in this (since I
have two modules that depend on Math::BigFloat heavily) and am already
involved in an existing offline discussion with two different people
about just such an overhaul.
Before we start messing with Configure options and such, could I suggest
that we apply the patch to 5.6.1 (since it is clearly a problem on the
described systems), and work on getting a better BigInt into 5.7.x.
John Peacock
Peter Prymmer wrote:
>
> 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