Am I correct in assuming that it is not a question of how "big" or "small" the values which you are working with are, but rather how many significant digits you need to work with?

8.98846567431158e+307 and 4.94065645841247e-324 seem large / small enough for most purposes, but if you need the full 300+ significant digits of accuracy, then Math::BigFloat or Match::BigInt are your only solution.

If about 14 significant digits are sufficient, then you do not seem to need these packages.

The number 14 is not at all magical. The Camel-book says:
To convert from number to string, it does the equivalent of an sprintf(3) with a format of "%.14g" on most machines. (Programming Perl, 3ed, p. 59)

This of course begs the question: How many significant digits are really used internally? It would take wiser monks than me, to answer that.

CountZero

"If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

\I'm not exactly sure how useful the code is, but the reference in the pod should be.

#! perl -slw

=pod Extract from [perlnumber]

 On typical hardware, floating point values can store
 numbers with up to 53 binary digits, and with binary  
exponents between -1024 and 1024. In decimal representation 
this is close to 16 decimal digits and decimal exponents in 
the range of -304..304. The upshot of all this is that Perl 
cannot store a number like 12345678901234567 as a floating 
point number on such architectures without loss of 
information.

 =cut
 
use strict;
use Math::BigFloat;

my $num = '1234567890123456789';

my $bf = Math::BigFloat->new();

for my $digits (14.. 17) {
    my $strnum = substr( $num, 0, $digits);
    $bf = Math::BigFloat->new( $strnum );
    my $double = 0+$strnum;
    print $bf, $bf - $double ? 'Use BigFloat': 'Use native';
}
__END__
12345678901234.Use native
123456789012345.Use native
1234567890123456.Use BigFloat
12345678901234567.Use BigFloat
[download]

my $i = 1.0;
my $lasti;
for (;;) {
   $lasti = $i;
   $i *= 2;
   print $i,"\n";
   last if ($i == $lasti);
}
[download]

A similar trick with division by 2 will give you the smallest representable float (4.94065645841247e-324 on my system).

Update: Basing the decision on the number of digits of precision in the range will not work in general. For example all the numbers could be from 0 to 1 but if you require 50 digits of precision you should use BigFloat.

use Data::Dumper;

$str = $ARGV[0];
$a = $str + 0.0;
if ($a =~ m/INF/) {
    use bignum;
    $a = $str + 0.0;
    no bignum;
}

print Dumper($a);
[download]

perl -w test.pl 9e5000, will give you a BigInt
perl -w 12.3, will give you a normal guy

Perhaps you can do some testing and see which datasets give the same answer the fast way and the slow way, then see if you can derive some emperical ideas from that.

The formal approach would be to compute tolerances along side the main calculation. This would cut the speed in half, but that's still nothing like the factor of 40 you have now. Then you can detect when the significance requires upgrading to bigfloat. In fact... you could write a lazybigfloat module that does this for you automatically. Then you can do some analysis and only employ it for expressions that might need it, like in the example above.

—John

This C code:

int main(void)
{
  double d;
  d=1.0;
  while(d>0.0)
  {
    printf("%100.80e\n",d);
    d = d/2.0;
  }
  return 1;
}
[download]

  my $d;
  $d=1.0;
  while($d>0.0)
  {
    printf("%100.80e\n",$d);
    $d = $d/2.0;
  }
[download]

  my $d;
  $d=1.0;
  while($d>0.0)
  {
    $d= "$d";
    printf("%100.80e\n",$d);
    $d = $d/2.0;
  }
[download]

2.38418579101562500000000000000000000000000000000000000000000000000000
+000000000000e-07
1.19209289550780998537093783879586839091757610731292515993118286132812
+500000000000e-07
[download]

2.38418579101562500000000000000000000000000000000000000000000000000000
+000000000000e-07
1.19209289550781250000000000000000000000000000000000000000000000000000
+000000000000e-07
[download]

It should work perfectly the first time! - toma

But how do you determine how many digits is too many on the current platform?

____________________
Jeremy
I didn't believe in evil until I dated it.

I haven't had problems with latitude/longitude/altitude, it's the elusive 'measurement' that shapefiles can contain that have been causing grief. The measurement value can be pretty much anything, if the lat/lon of the point represents a point in a river, the measurement might indicate flow rate, water temperature, depth, salinity, radioactivity, whatever it is that you need to measure for your application.

Math::BigInt::FastCalc and Math::BigInt::BitVect ( + Bit::Vector) seem like better alternatives to me, as well as Math::BigInt::Pari and Math::BigInt::GMP (I'm just quoting from the docs now, I have no experience with any of the latter). Enough choice for alternatives, I would say.

I do wonder why a pure perl calculation library is the default. Hmm...