Click here to get back home

bignum 0.22

 HomeNewsGroups | Search | About
 comp.lang.perl.modules    Post an article   get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content
Subject Author Date
bignum 0.22 gamo 07-04-2007
`--> Re: bignum 0.22 José Luis Pérez...07-05-2007
Posted by Mumia W. on July 6, 2007, 5:58 am
Please log in for more thread options


On 07/06/2007 03:53 AM, gamo wrote:
> On Fri, 6 Jul 2007, Mumia W. wrote:
>
>> [...]
>> Gamo, why did you choose bignum rather than bigint?
>>
>>
> Because it's simple to use. It overloads any operation.
> Fire and forget. No OOP nor especial commands.
> If I need to use only BigInt, I'll check GMP::Mpz or Math::PARI, too.
> PARI is another kind of animal, because it does functions.
> Best regards,
>

"Bigint" is the same way, and I'm talking about the "bigint" pragma--not
the Math::BigInt module.

Want your program to run like a bat out of hades? Install
Math::BigInt::GMP and the binary GMP library. Then put this at the top
of your program:

use bigint 'lib', 'GMP';

This gets you (nearly) the simplicity of normal Perl numbers with the
accuracy of Math::BigInt with the breathtaking speed of GMP.

Yes, I tested it.
:-)~~~~


Posted by Sisyphus on July 6, 2007, 11:45 am
Please log in for more thread options



news:NXkji.4428
.
.
>
> Yes, I also noticed that Math::BigInt (or "bigint") works right out of the
> box.
>
> Evidently "bignum" has more to do and is more complicated, and
> consequently, has more bugs. In this case, I don't know if the bug is in
> the documentation or code; however, I think that the default accuracy
> should be given in the POD.
>
> Nonetheless, it can be queried by calling Math::BigFloat->accuracy().
>

Aaah ... the division in gamo's code means that the bignums are
Math::BigFloat objects rather than Math::BigInt objects ... and, according
to the Math::BigFloat documentation, Math::BigFloat sets the default value
of "div_scale" to 40.

So it's really just the price one pays for relying on bignum to DWIM (which
it fails to do wrt the original code that was posted), instead of using
Math::BigInt.

Cheers,
Rob


Posted by xhoster on July 6, 2007, 12:46 pm
Please log in for more thread options


> news:NXkji.4428
> .
> .
> >
> > Yes, I also noticed that Math::BigInt (or "bigint") works right out of
> > the box.
> >
> > Evidently "bignum" has more to do and is more complicated, and
> > consequently, has more bugs. In this case, I don't know if the bug is
> > in the documentation or code; however, I think that the default
> > accuracy should be given in the POD.
> >
> > Nonetheless, it can be queried by calling Math::BigFloat->accuracy().
> >
>
> Aaah ... the division in gamo's code means that the bignums are
> Math::BigFloat objects rather than Math::BigInt objects

Hmmm. Why is that? It seems like BigInt overloads division to be bdiv,
not fdiv. And bignum doesn't seem to overload anything, it relies on
BigInt to do the overloading.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB

Posted by Sisyphus on July 6, 2007, 9:28 pm
Please log in for more thread options



.
.
>> Aaah ... the division in gamo's code means that the bignums are
>> Math::BigFloat objects rather than Math::BigInt objects
>
> Hmmm. Why is that? It seems like BigInt overloads division to be bdiv,
> not fdiv. And bignum doesn't seem to overload anything, it relies on
> BigInt to do the overloading.
>

In Math::Big Int, the 'bdiv' operation (which is the overload function for
the division operator) contains the following code:
---------------------------------
return $upgrade->bdiv($upgrade->new($x),$upgrade->new($y),@r)
if defined $upgrade;
---------------------------------

Presumably bignum sets $Math::BigInt::upgrade to 'Math::bigFloat'.

The test script:
----------------------------------
use warnings;
use Math::BigInt;
use Math::BigFloat;

$Math::BigInt::upgrade = 'Math::BigFloat'; # line 5

$x = Math::BigInt->new(2);
$y = Math::BigInt->new(7);
$z = $y / $x;
print ref($z), "\n";
----------------------------------

That prints out 'Math::BigFloat', but if line 5 is commented out it prints
out 'Math::BigInt'.

Cheers,
Rob



Posted by José Luis Pérez Diez on July 5, 2007, 7:46 am
Please log in for more thread options


> I found a problem related with calculating Catalan's numbers
>
> #!/usr/local/bin/perl -w
>
> use bignum;
>
^^
use bingnum qw(p 0); #instead see perldoc bignum;

> while (1){
> $n++;
> # $Cat = (fact(2*$n))/((n+1)!n!)
> $Cat = (fact(2*$n))/(($n+1)*fact($n)**2);
> print "$Cat\n";
> last if length $Cat > 78;
> }
>


To use this algoritm the precison must be 0 because all the numbers are
integers.

133 =
43247909631719355347185999181748231619129200590055369794426007640095877
732860
134 =
17106950920991211670664684120780411618233328233399679607572954133193480
5254424
135 =
67673085260979940285423529830734275372128901393889909035840068556309503
8432942
136 =
26772855628796443528977776035224800913645156609845496859434538071182300
06063172



Similar ThreadsPosted
Problem around bignum March 28, 2006, 6:04 am
bignum incompatible with loos_like_number ??? June 26, 2007, 10:05 pm
bignum incompatible with looks_like_number() ??? June 26, 2007, 10:17 pm
Error in perl module "bignum"... May 14, 2006, 4:31 pm

Our other projects:

Art Dolls, Fairies and Mermaids - Sunnyfaces.net

Roy's Linux, Programming and Search Engines messages

1-Script XML SitemapXML Sitemap