http://qs321.pair.com?node_id=534842

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

This is why I prefer to keep things as rationals (or bigrats), rather than floats - it's possible to represent them accurately without encountering the inevitable rounding or truncating errors. True, all the irrational numbers will still truncate, but the rationals won't. I only use the decimal representation for display purposes, sometimes.

• Comment on Re^4: Help me make a test case for Math::BigFloat

Replies are listed 'Best First'.
Re^5: Help me make a test case for Math::BigFloat
by fizbin (Chaplain) on Mar 07, 2006 at 07:01 UTC
Note that all the brokenness here can be gotten also by saying use bigrat; instead of use bignum; - there's something about those modules that causes weirdness with exp of certain close-to-zero quantities. (but not all - change the -7e-17 to a -7e-18 and all is right with the universe again.)
--
```@/=map{[/./g]}qw/.h_nJ Xapou cets krht ele_ r_ra/;
map{y/X_/\n /;print}map{pop@\$_}@/for@/

AFAIK, there's no exp function for bigrat or Math::BigRat. It's a deficiency I'd like to fix, but I've never been able to work out an algorithm for calculating exp for rationals. There are certain series, of course, but they are unacceptably slow for practical use.

I've never been able to work out an algorithm for calculating exp for rationals.
That's probably because exp(r) is irrational for every rational r except for 0. However, saying use bigrat sprinkles some magic crazy dust over the whole program in a way similar to use bignum; witness:
```use bigrat;
use strict;
my \$lnev = - 7 / (10 ** 17);
print "lnev is \$lnev\n";
my \$ev = exp(\$lnev);
print "ev is \$ev\n";
print "1-ev is ", 1-\$ev, "\n";
```@/=map{[/./g]}qw/.h_nJ Xapou cets krht ele_ r_ra/;