Yes, Brian, you're right, it seems that it is enough to use a FatRat for
the first term, even with an integer input of 400. Thank you very much.
Quite likely because the first term's denominator is the only one that is
growing very fast with an exponentiation, 16 ** $k, while the others only
have multiplications and their growth is much slower.
And BTW, with a summation of the Plouffe terms from 0 to 400, I now get 491
correct digits for pi in less than one second. This is incredibly fast
compared to the other infinite formulas I had tried before (Stévin, Wallis,
Newton, etc.) that converge very slowly. And the code is really simple.
Thank you both, Fernando and Brian, for your help, this solves my little
but interesting problem.
Laurent.
Le ven. 19 avr. 2019 à 18:46, Brian Duggan <bdug...@matatu.org> a écrit :
> It looks like one FatRat is enough :-)
>
> $ cat fat.p6
> sub plouffe (Int $k) {
> my $result = (1.FatRat / 16 ** $k) * ( (4 / (8 * $k + 1)) - (2 /
> (8 * $k + 4)) - (1 / (8 * $k + 5)) - (1 / (8 * $k + 6) ) );
> }
>
> say (plouffe $_).WHAT for 0..15;
>
> say [+] (plouffe $_ for 0..15)
>
> $ perl6 fat.p6
> (FatRat)
> (FatRat)
> (FatRat)
> (FatRat)
> (FatRat)
> (FatRat)
> (FatRat)
> (FatRat)
> (FatRat)
> (FatRat)
> (FatRat)
> (FatRat)
> (FatRat)
> (FatRat)
> (FatRat)
> (FatRat)
> 3.141592653589793238462593174670682882792683045699610435502
>
>
> On Friday, April 19, Laurent Rosenfeld via perl6-users wrote:
> > Thank you very much, Fernando, I'll try that as soon as I get back home.
> >
> > Cheers,
> > Laurent.
> >
> >
> > Le ven. 19 avr. 2019 à 16:00, Fernando Santagata <
> nando.santag...@gmail.com>
> > a écrit :
> >
> > > This one works fine:
> > >
> > > sub plouffe (Int $k) {
> > > my $result = 1.FatRat * (1 / 16 ** $k).FatRat * ((4 / (8 * $k +
> > > 1)).FatRat - (2 / (8 * $k + 4)).FatRat - (1 / (8 * $k + 5)).FatRat -
> (1 /
> > > (8 * $k + 6)).FatRat );
> > > }
> > >
> > > say (plouffe $_).WHAT for ^20
> > >
> > > I guess that until a certain point all the terms not specifically cast
> to
> > > FatRat are of type Rat. After reaching the maximum possible Rat they're
> > > converted to Num and FatRat * Num = Num.
> > >
> > > On Fri, Apr 19, 2019 at 3:37 PM Laurent Rosenfeld via perl6-users <
> > > perl6-us...@perl.org> wrote:
> > >
> > >> Hello,
> > >>
> > >> in the context of the Perl Weekly Challenge, I was trying to use one
> of
> > >> Franco-Canadian mathematician Simon Plouffe's formulas to compute the
> > >> digits of pi.
> > >>
> > >> For this, I have written the following subroutine:
> > >>
> > >> sub plouffe (Int $k) {
> > >> my $result = (1 / 16 ** $k) * ( (4 / (8 * $k + 1)) - (2 / (8 *
> $k
> > >> + 4)) - (1 / (8 * $k + 5)) - (1 / (8 * $k + 6) ) );
> > >> }
> > >>
> > >> With this, it should be possible to compute the pi decimals with
> > >> something like this:
> > >>
> > >> > my $k = [+] (plouffe $_ for 0..15)
> > >> 3.141592653589793129614170564041344859
> > >> >
> > >>
> > >> That doesn't work properly, however as the digitss are wrong after a
> > >> certain rank (16th). The reason seems to be that, after a while,
> rationals
> > >> are converted to floats and precision is lost:
> > >>
> > >> > say (plouffe $_).WHAT for 0..15;
> > >> (Rat)
> > >> (Rat)
> > >> (Rat)
> > >> (Rat)
> > >> (Rat)
> > >> (Rat)
> > >> (Rat)
> > >> (Rat)
> > >> (Rat)
> > >> (Rat)
> > >> (Rat)
> > >> (Num)
> > >> (Num)
> > >> (Num)
> > >> (Num)
> > >> (Num)
> > >> >
> > >>
> > >> So, for an input value of 11 or more, the plouffe subroutine returns a
> > >> Num.
> > >>
> > >> So I decided to try with FatRat:
> > >>
> > >> sub plouffe (Int $k) {
> > >> my $result = 1.FatRat * (1 / 16 ** $k) * ( (4 / (8 * $k + 1)) -
> (2
> > >> / (8 * $k + 4)) - (1 / (8 * $k + 5)) - (1 / (8 * $k + 6) ) );
> > >> }
> > >>
> > >> It is a bit better, but I am again falling back to Num when the
> > >> subroutine input value reaches 17 or above:
> > >>
> > >> > say (plouffe $_).WHAT for 0..20;
> > >> (FatRat)
> > >> (FatRat)
> > >> (FatRat)
> > >> (FatRat)
> > >> (FatRat)
> > >> (FatRat)
> > >> (FatRat)
> > >> (FatRat)
> > >> (FatRat)
> > >> (FatRat)
> > >> (FatRat)
> > >> (FatRat)
> > >> (FatRat)
> > >> (FatRat)
> > >> (FatRat)
> > >> (FatRat)
> > >> (Num)
> > >> (Num)
> > >> (Num)
> > >> (Num)
> > >> (Num)
> > >>
> > >> Has anyone an idea why we are not keeping FatRat values all the way?
> Or,
> > >> is there a better way to guarantee that we continue to use FatRat's?
> > >>
> > >> Note that I have found other ways of computing many pi digits, but the
> > >> one described above would be much simpler and much more elegant, if
> only it
> > >> worked OK. So my question is really not how to compute pi's digits,
> but
> > >> more this: why are the above computations falling from FatRat to Num
> after
> > >> a while, and is there something to do to keep FatRat calculation all
> the
> > >> way?
> > >>
> > >> Thanks to anyone who would be able to shed light on this.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > > --
> > > Fernando Santagata
> > >
>
