bignum 0.22

Hello

I found a problem related with calculating Catalan's numbers

#!/usr/local/bin/perl -w

use 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;
}

sub fact {
my $i = shift;
my $f = 1;
while ($i>1){
$f *= $i;
$i--;
}
return $f;
}

__END__

TIA

--
http://www.telecable.es/personales/gamo/
perl -e 'print 111_111_111**2,"\n";'

Re: bignum 0.22

"gamo" wrote in message
news:Pine.LNX.4.64.0707041540080.19628@jvz.es...
>
> Hello
>
> I found a problem related with calculating Catalan's numbers
>

What is the problem ? (I don't see it.)

Cheers,
Rob

Re: bignum 0.22

In article , Gamo wrote:
> 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 =
432479096317193553471859991817482316191292005900553697944260 07640095877
732860
134 =
171069509209912116706646841207804116182333282333996796075729 54133193480
5254424
135 =
676730852609799402854235298307342753721289013938899090358400 68556309503
8432942
136 =
267728556287964435289777760352248009136451566098454968594345 38071182300
06063172

Re: bignum 0.22

On 07/05/2007 04:36 AM, gamo wrote:
> On Thu, 5 Jul 2007, Sisyphus wrote:
>
>> "gamo" wrote in message
>> news:Pine.LNX.4.64.0707041540080.19628@jvz.es...
>>> Hello
>>>
>>> I found a problem related with calculating Catalan's numbers
>>>
>> What is the problem ? (I don't see it.)
>>
>> Cheers,
>> Rob
>>
>
> The problem is that this output lacks precision aparently
>
> 216489185503133990863274261791925599831200000000000000000000
> 853702637172735926234421145556838686126800000000000000000000
> 336693937277471552215818433107463481818200000000000000000000 0
> [...]

You can set the "accuracy" of the bignum module. Read "perldoc bignum"

BTW, if you make fact() recursive and use the Memoize module, you can
get a speed improvement--a /substantial/ speed improvement :-)

Re: bignum 0.22

On Thu, 5 Jul 2007, Mumia W. wrote:

> You can set the "accuracy" of the bignum module. Read "perldoc bignum"
>
> BTW, if you make fact() recursive and use the Memoize module, you can get a
> speed improvement--a /substantial/ speed improvement :-)
>
Thanks all of you.
This trick really really improve speed.

But if there is no previous knowledge that all numbers will be
integers I can not fix the precision or accuracy.

Cheers

Re: bignum 0.22

gamo wrote:
> On Thu, 5 Jul 2007, Mumia W. wrote:
>
> > You can set the "accuracy" of the bignum module. Read "perldoc bignum"
> >
> > BTW, if you make fact() recursive and use the Memoize module, you can
> > get a speed improvement--a /substantial/ speed improvement :-)
> >
> Thanks all of you.
> This trick really really improve speed.
>
> But if there is no previous knowledge that all numbers will be
> integers

Aren't Catalan numbers only defined on integers?

> I can not fix the precision or accuracy.

Choosing to leave the defaults in place is still a choice, and you should
understand what the consequences of that choice are. It is not for the
accuracy and precision to be infinite. They are still limited through
some confusing fall-back method.


Xho

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

Re: bignum 0.22

"Mumia W." wrote in message
news:hq7ji.3972$Od7.1277@newsread1.news.pas.earthlink.net...
> On 07/05/2007 04:36 AM, gamo wrote:
>> On Thu, 5 Jul 2007, Sisyphus wrote:
>>
>>> "gamo" wrote in message
>>> news:Pine.LNX.4.64.0707041540080.19628@jvz.es...
>>>> Hello
>>>>
>>>> I found a problem related with calculating Catalan's numbers
>>>>
>>> What is the problem ? (I don't see it.)
>>>
>>> Cheers,
>>> Rob
>>
>> The problem is that this output lacks precision aparently
>>
>> 216489185503133990863274261791925599831200000000000000000000
>> 853702637172735926234421145556838686126800000000000000000000
>> 336693937277471552215818433107463481818200000000000000000000 0
>> [...]
>
> You can set the "accuracy" of the bignum module. Read "perldoc bignum"
>

Oh, yes ... I should've realised.

Is that a bug in bignum ? I didn't see it documented anywhere that there was
a default "accuracy" set.
The same issue does not arise if you explicitly 'use Math::BigInt;'.

Cheers,
Rob

Re: bignum 0.22

On 07/05/2007 10:08 PM, Sisyphus wrote:
>
> "Mumia W." wrote in message
> news:hq7ji.3972$Od7.1277@newsread1.news.pas.earthlink.net...
>> On 07/05/2007 04:36 AM, gamo wrote:
>>> On Thu, 5 Jul 2007, Sisyphus wrote:
>>>
>>>> "gamo" wrote in message
>>>> news:Pine.LNX.4.64.0707041540080.19628@jvz.es...
>>>>> Hello
>>>>>
>>>>> I found a problem related with calculating Catalan's numbers
>>>>>
>>>> What is the problem ? (I don't see it.)
>>>>
>>>> Cheers,
>>>> Rob
>>>
>>> The problem is that this output lacks precision aparently
>>>
>>> 216489185503133990863274261791925599831200000000000000000000
>>> 853702637172735926234421145556838686126800000000000000000000
>>> 336693937277471552215818433107463481818200000000000000000000 0
>>> [...]
>>
>> You can set the "accuracy" of the bignum module. Read "perldoc bignum"
>>
>
> Oh, yes ... I should've realised.
>
> Is that a bug in bignum ? I didn't see it documented anywhere that there
> was a default "accuracy" set.
> The same issue does not arise if you explicitly 'use Math::BigInt;'.
>
> Cheers,
> Rob

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().

Gamo, why did you choose bignum rather than bigint?

Re: bignum 0.22

On Fri, 6 Jul 2007, Mumia W. wrote:

> On 07/05/2007 10:08 PM, Sisyphus wrote:
> >
> > "Mumia W." wrote in message
> > news:hq7ji.3972$Od7.1277@newsread1.news.pas.earthlink.net...
> > > On 07/05/2007 04:36 AM, gamo wrote:
> > > > On Thu, 5 Jul 2007, Sisyphus wrote:
> > > >
> > > > > "gamo" wrote in message
> > > > > news:Pine.LNX.4.64.0707041540080.19628@jvz.es...
> > > > > > Hello
> > > > > >
> > > > > > I found a problem related with calculating Catalan's numbers
> > > > > >
> > > > > What is the problem ? (I don't see it.)
> > > > >
> > > > > Cheers,
> > > > > Rob
> > > >
> > > > The problem is that this output lacks precision aparently
> > > >
> > > > 216489185503133990863274261791925599831200000000000000000000
> > > > 853702637172735926234421145556838686126800000000000000000000
> > > > 336693937277471552215818433107463481818200000000000000000000 0
> > > > [...]
> > >
> > > You can set the "accuracy" of the bignum module. Read "perldoc bignum"
> > >
> >
> > Oh, yes ... I should've realised.
> >
> > Is that a bug in bignum ? I didn't see it documented anywhere that there was
> > a default "accuracy" set.
> > The same issue does not arise if you explicitly 'use Math::BigInt;'.
> >
> > Cheers,
> > Rob
>
> 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().
>
> 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,

--
http://www.telecable.es/personales/gamo/
perl -e 'print 111_111_111**2,"\n";'

Re: bignum 0.22

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.
:-)~~~~

Re: bignum 0.22

"Mumia W." wrote in message
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

Re: bignum 0.22

"Sisyphus" wrote:
> "Mumia W." wrote in message
> 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

Re: bignum 0.22

wrote in message
news:20070706124605.776$m9@newsreader.com...
..
..
>> 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