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
