Yeah; I'll admit that once I pulled the code into a pretty format for the SOPW it stopped looking so ugly, convoluted, and in need of beating down into minimalness as it did when it was just four tight lines in my command window following a -e.
--


@/=map{[/./g]}qw/.h_nJ Xapou cets krht ele_ r_ra/;
map{y/X_/\n /;print}map{pop@$_}@/for@/
[download]

Along those lines, I'd suggest streamlining it even more and submitting it as a test file (i.e. use Test::More instead of print. For example:

use strict;
use warnings;
use Test::More tests => 3;
use bignum;

sub xe{
 $_[0]*log($_[0])+log(atan2(1,1)*8*$_[0])/2
  + 1/(12*$_[0]) - 1/(360*($_[0]**3)) + 1/(1260*($_[0]**5));
}

my ($m, $n, $r) = ( 2**96, 3*(10**6), 1*(10**6) );

my $e=exp(xe($m-$n)+xe($m-$r)-xe($m)-xe($m-$n-$r));

is( $e      , 1,    '$e should equal 1'     );
is( 1-$e    , 0,    '1-$e should equal 0'   );
is( 1-"$e"  , 0,    '1-"$e" should equal 0' );
[download]

Gives:

1..3
ok 1 - $e should equal 1
not ok 2 - 1-$e should equal 0
#     Failed test (bigtest.pl at line 17)
#          got: '1'
#     expected: '0'
ok 3 - 1-"$e" should equal 0
# Looks like you failed 1 test of 3.
[download]

That's even easier for a module author to work with.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

I don't think this is a bug, just an artifact of the transition between IEEE float constants and bignum objects:

c:\>perl -MMath::BigFloat 
-wle"print Math::BigFloat->new(1) - Math::BigFloat->new( .999999999999
+999 )"
0.000000000000001

c:\>perl -MMath::BigFloat 
-wle"print Math::BigFloat->new(1) - Math::BigFloat->new( .999999999999
+9999 )"
0

c:\>perl -MMath::BigFloat 
-wle"print Math::BigFloat->new(1) - Math::BigFloat->new('.999999999999
+9999')"
0.0000000000000001

c:\>perl -MMath::BigFloat 
-wle"print Math::BigFloat->new(1) - Math::BigFloat->new('.999999999999
+99999999999')"
0.00000000000000000000001
[download]

Notice how once you get beyond ~16 decimal places in the constant, the result is wrong. However, if you pass the constant as a string rather than allowing Perl to convert it to a IEEE float before passing it to bignum, the accuracy is retained.

So the answer is to use string constants to initialise your bignum objects.

I don't care what I'm initializing something with, there shouldn't be any way to create $ev such that both $ev and 1-$ev print as "1".

And as for initializing everything as strings, look at this code:

#!perl
use Math::BigFloat;
print ((new Math::BigFloat("1")) -
       exp(new Math::BigFloat("-7") /
             (new Math::BigFloat("10")**(new Math::BigFloat("17")))));
# Properly prints "0"
# (well, something like 7e-17 would be closer, but I'll accept 0)
[download]

Compare it to this code, which is the same but with a use bignum:

#!perl
use bignum;
use Math::BigFloat;
print ((new Math::BigFloat("1")) -
       exp(new Math::BigFloat("-7") /
             (new Math::BigFloat("10")**(new Math::BigFloat("17")))));
# Incorrectly prints "1"
[download]

It would appear then that we have a bug not so much in Math::BigFloat directly, but somewhere in the intersection of Math::BigFloat, bignum, and the magic bignum sprinkles on exp.
--


@/=map{[/./g]}qw/.h_nJ Xapou cets krht ele_ r_ra/;
map{y/X_/\n /;print}map{pop@$_}@/for@/
[download]

Hmm. There seem to be two interacting problems here.

1. exp doesn't appear to be overloaded by either bignum or Math::BigFloat?

   #!perl -slw
   use strict;
   use overload;
   #use bignum;
   use Math::BigFloat;
   
   printf "exp(-7e-17): %.17f\n", my $exp = exp( Math::BigFloat->new( '-7
   +e-17' ) );
   
   eval{ print overload::Overloaded( $exp ) } or warn $@;
   print overload::StrVal( $exp );
   
   printf "1-exp(-7-e17): %.17f\n", Math::BigFloat->new("1") - $exp;
   __END__
   C:\test>junk7
   exp(-7e-17): 0.99999999999999989
   Can't call method "can" without a package or object reference at c:/Pe
   +rl/lib/overload.pm line 54.
   1
   1-exp(-7-e17): 0.00000000000000000
   [download]

2. And with bignum enabled, Math::BigFloat seems to forget how to do math? At least if the math involves one BigMath object and one normal perl number.

   #!perl -slw
   use strict;
   use overload;
   use bignum;
   use Math::BigFloat;
   
   printf "exp(-7e-17): %.17f\n", my $exp = exp( Math::BigFloat->new( '-7
   +e-17' ) );
   
   eval{ print overload::Overloaded( $exp ) } or warn $@;
   print overload::StrVal( $exp );
   
   printf "1-exp(-7-e17): %.17f\n", Math::BigFloat->new("1") - $exp;
   
   __END__
   C:\test>junk7
   exp(-7e-17): 0.99999999999999989
   Can't call method "can" without a package or object reference at c:/Pe
   +rl/lib/overload.pm line 54.
   1
   1-exp(-7-e17): 1.00000000000000000
   [download]

All of which makes me glad that I rarely need the accuracy beyond 53-bits and when I do, 64-bit ints suffice.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

use Math::BigFloat;

my $one_minus_one = Math::BigInt->new(1) - Math::BigFloat->new(.9999);
print "$one_minus_one\n";
[download]

#!perl
use bignum;

my $tmp = "-0.00000000000000007573064690121714";
my $e = exp($tmp);

printf("%3.20g\n", $e);
print "$e ", 1-$e, "\n";
[download]

Wow, this is mighty strange... I added some more prints of calculations, as so:

printf "%3.5g %3.5g %3.5g %3.5g\n",
  ($e+0), (0+$e), (0-$e),($e-0);

printf "%3.5g %3.5g %3.5g %3.5g\n",
  ($e+1), (1+$e), (1-$e),($e-1);

printf "%3.5g %3.5g %3.5g %3.5g\n",
  ($e+$e), ($e-$e), ($e*$e),($e/$e);

printf "%3.5g %3.5g %3.5g %3.5g\n",
  ($e**2), ($e**0), (0/$e),($e/0);
[download]

The output was:

  0   0   0   0
  1   1   1  -1
  2   0   1   1
  0   1   0   0
[download]

In particular, note that the final calculation is ($e/0). The anomaly is more than just $e having an ambiguous value, it seems.