[% setvar title Integrate BigInts (and BigRats) Support Tightly With The Basic Scalars %]
|Note: these documents may be out of date. Do not use as reference!|
To see what is currently happening visit http://www.perl6.org/
Integrate BigInts (and BigRats) Support Tightly With The Basic Scalars
Maintainer: Jarkko Hietaniemi <firstname.lastname@example.org> Date: 5 Aug 2000 Mailing List: email@example.com Number: 43 Version: 1 Status: Developing
Currently Perl 'transparently' starts using double floating point numbers when the numeric values grow too large for the native integer types (int, long, quad) can no more hold quantities that large. Because double floats are at their heart a lie, they cannot truly represent large numbers accurately. Therefore sometimes when the application would prefer to stay accurate, the use of 'bigints' (and for division, 'bigrats') would be preferable. Classes of applications that would prefer keeping true: cryptography, financial, statistics (combinatorics).
When the following pragma is in effect all numeric SVs (or, rather, the numeric ops) would try to keep their results as big integers. "Try to" because some math simply doesn't play along: sin(), ln(), etc.
use bigint; my $thats_big_baby = 5**5**5;
With only "use bigint" in scope 2/3 would fall back to .6666...7, but with the following pragma, it would be truly 2/3:
If one wants to limit the bigintism or -ratism to just a few select scalars, one could use 'strong typing':
my bigint $i; my bigrat $r;
Either include (if there is a bigint library with the appropriate features and licensing) a bigint library or implement one.
For performance reasons the bigint library needs to operate using the native integer types. We don't want 1+1 engaging the whole bigint machinery.
RFC 38 [Standardise Handling Of Abnormal Numbers Like Infinities And NaNs]