Note: this article makes use of MathML, the standard XML markup for math formulas. Sadly, this is not properly supported on some allegedly ‘modern’ and ‘feature-rich’ browsers. If the formulas don't make sense in your browser, consider reporting the issue to the respective developers and/or switching to a standard-compliant browser.

I recently came across this interesting article (blog post?) from the Fediverse showing a nifty trick to compute multiples of π by relying on only two products: by 3, and by 14. I encourage you to read the article if you're interested in the method because it's crystal clear, whereas I'm going to muddy the waters a bit, throwing my considerations at it.

The reason why the proposed idea works is that the first digits of the fractional part of the decimal expansion of π can be expressed as multiples of 14. Indeed, the fractional part of π=3.14159265359...

0.141592 14 14 14 7 -21

This effectively means that

π=3.14159265359...=3+1410-2+1410-4+1410-5+...

and thus

kπ=3k+14k(10-2+10-4+10-5+...)

which is interesting because 10-x means “shifting your results right by x digits”, which is particularly nice if k is an integer up to 7, and thus 7k has two digits, and the first two terms in the expansion are shifted by two and four digits (no need to take any actual summation).

Let's make the example with k=7, and try to compute

7π=21.991148575...

This may seem to be an arbitrary divergence from Cook's example, but is actually needed to discuss one of the limitations of the approach: spillover. We have 3k=21, 14k=98, and thus the first terms (up to what Cook's calls the simplest approach) are:

7π21.9898

(relative error is <6.210-5 —note that this is the same found by Cook, even though he discusses the absolute error instead)

Things get a bit hairier on the first refinement, because the value of 14k now needs to be shifted by one more digit, not two. And while in Cook's example with k=4 he has 14k=56 and 560+56=616 (remove the last two digits, replace with the new three digits) in our case there's a bit of a spillover: 980+98=1078, so this refinement doesn't lend itself to a simple substitution of the last two digits:

7π21.99078

(relative error <1.710-5.)

The next refinement is a bit more involved, because (you may notice the 7 in the tableau at the top of this article) it involves halving our 14k —which, coincidentally, is always possible because 14 is even— and adding it in the same place. In our case, this means adding another 49 to the last two digits, and once again we have a small spillover (luckily into a 0):

7π=21.99127.

The relative error is now <5.610-6, more than order of magnitude better than the initial result, and —interestingly— it is now an overestimation.

Alternatives

If you go read the Fediverse thread, you'll notice that I raised the question of the comparison with approximations compute from the well-known rational approximations of π, i.e.

227=3+17

and

355113=3+16113=3+17-1791

Aside from the somewhat contrived case of k=7 I'm using here an example, multiples of these fractions would be harder to compute, as observed by Bill Ricker, although the multiple of 355/113 would still be more accurate.

What is interesting is that the second refinement presented by Cook can be further refined, e.g. by replacing the last “half 14k” contribution with a “3/8th of 14k” contribution. This is less trivial to compute, unless we consider that 3/8=1/2-1/8, so we can correct Cook's refinement by subtracting the “half 14k divided by 4”, which in our case is 49/4=12.25.

Even if we truncate this to 12, the fixup gives us

7π21.99115

with a relative error that is now <6.510-8, which is now two orders of magnitude lower. (The actual correction would be 7π21.9911475 with a relative error <510-8.)

What is impressive about this particular result is that the relative error is not only of the same order as the one given by the 355/113 approximation, but actually slightly better (the relative error for 355/113 is closer to 8.510-8).

A summary

To get a good approximation of a multiple of π:

  1. multiply by 3 (call this u);
  2. multiply by 14 (call this f);
  3. add: u,
    f shifted by 2 digits,
    f shifted by 4 digits,
    f shifted by 5 digits;
  4. bonus: add
    f/2 shifted by 5 digits;
  5. extra: subtract
    f/8 shifted by 5 digits
    (note that f/8 can be computed as (f2)/4).

An alternative to the last two points, getting to the same results, would be to add f/4+f/8 (this time computing f/8 as half of f/4) shifted by 5 digits.

Let's apply to this to Cook's example for 4π:

  1. 4×3=12;
  2. 4×14=56;
  3. 12+0.56+0.0056+0.00056=12.56616;
  4. bonus: 56/2=2812.56644
    (note that Cook's post has a couple of typos in this line; absolute error is still <710-5);
  5. extra: 28/4=712.56637
    (absolute error is now <6.210-7; note that the extra division by 4 is particularly easy to do in Cook's example).

with the possibility to replace 4. and 5. with

564=14,142=712.56616+0.00014+0.00007=12.56630+0.00007=12.56637.

Note however that 12.5663 is slightly worse than 12.56644 as an approximation (error 7.110-5 rather than <710-5, in addition of being of the opposite sign.) Note also that the best approximation we've discussed so far (12.56637) is also the midpoint of these two.

Smallest doesn't mean easier to handle

I believe that one of the most important discoveries to which this trick has led me is the importance of the difference between the compactness of the (approximating) fraction and how easy it is to handle.

This isn't something entirely new to me (I've always known that in computing there are several series that help find out new digits of π faster), but what I learned this time is how this maps to “human computing”.

If we write the full mathematical expression of the π approximant that leads to the algorithm we just described we have:

π3+14100(1+1100+11000(1+12(1-14)))  ()

which is considerably more complex than the expressions we have from the continued fraction expansion,

π227=3+17

or even my beloved Milü

π355113=3+16113=3+17-1791=3+17(1-1113).

Yet, except for particular cases, the divisions by 7 and 113 involved in the latter expressions are likely to be more complex than the “multiply by 14, divide by 100”, because the division by 100 in the decimal system is a simple shift by two digits.

To wit, if we have computed 1/7 for the 22/7 approximation, it would be simpler to approximate π as

2199700=3+17-1700=3+17(1-1100)

than with the 355/113 expansion, since the last term is obtained simply by shifting by two digits the already computed division by 7. Even 3+1/7-1/800 (more accurate, but still not as much as 355/113) would be faster than the full 355/113 contribution.

Sevenths

Incidentally, here's an interesting fact:

17=0.(142857)=14100+2141002+4141003+8141004+...

and if we factor 14/100 (recognize it yet?)

17=14100(1+2100+41002+81003+)=14100i=02i100i.

Now, if we compute 1/7(1-1/100) as discussed above, we get

17(1-1100)=14100(1+1100+21002+41003+)

and you may notice that the first two terms are the same as the ones in the mind trick formula (). Where they start to diverge is on the third term, which is 2/10000=1/5000 here, but (after simplifications) 11/8000 in the mind trick formula.

This divergence should not surprise, since 1/7-1/700 is actually a pretty poor approximation for π-3. If we try 1/7-1/800, the first terms are a bit more complex to compute:

17-1800=17(1-781100)=14100(1+981100+25811002+...)

but we can make it easier to compare with () by rearranging the terms as

17-1800=14100(1+1100+181100+25811002+...)

so that the third term would be:

100811002+25811002=125810000=1880=1640

(compare 125/80000 to the mind trick's 110/80000.)

Speed versus accuracy

One of the key point in determining the approach to use to find approximate values to multiples of π is to take into account the accuracy of the multiplier.

As an example, assume we want to compute the circumference of the Earth, knowing that the radius is approximately r=6500 km. We want to compute 2πr or 13000π.

One would be tempted to use the magic algorithm that has been the main topic of discussion of this article, but that would actually be a waste of brainpower in this case, since the approximation for the radius is quite large already: there's no need to compute 13000π to particularly high accuracy, and in fact in this case the 3+1/7 approximation of π is sufficient: the first part is trivial, 3×13000=39000, and the rest is

130007=140007-100072000-140

(the next term from 1/7 would be 140/100, already too precise) which gives us a circumference of some 40960 km.

The attentive reader who remembers when the meter was defined as the 40-millionth part of the circumference of the Earth, will have noticed that we're way over the expected 40000 km, which is due to the fact that the (average) Earth radius is actually less than 6400. If we want to redo these computations, this time with 12800π, we have:

3×12800=38400

and leveraging the approximation 200/728:

1280071828

giving us a circumference of 38400+1828=40228, which is still too large (and for the curious: no, using a more accurate approximation wouldn't solve the issue, dropping it only to around 40212.)

Reciprocal problem

Maybe it would be better to work things the other way: assuming we know that circumference is 40000 km, can we work out a more accurate value of the radius? This means computing 20000/π. This is actually another one of those cases where the simpler, harder to manipulate fractions are easier to use, since their reciprocal is 1/π.

In our case

20000π20000722=70000116364

(the division by 11 is easy to do in mind: 66 from 70 is 4, 33 from 40 is 7, and then it repeats). This is actually a pretty good approximation to the actual Earth radius, that is closer to 6371 km. (Note also that using actual π here would only give marginally better results with an integer part of 6366: our approximation is accurate enough.)

So this got me wondering: could we build an approximant to 1π that is as easy to handle as () and the corresponding algorithm? From a quick look, the answer seems to be … “ish”. We have

1π=0.318309886...

so from a cursory look the best candidate to replace the 14/100 in () is 318/1000, and our shifts will be of three rather than two digits:

1π3181000(1+11000(1-3100))

which is considerably less manageable than (), especially after the second term, because of the three-digit numbers, although it does give us pretty low relative errors right from the start, approximately 9.7410-4,2.5510-5,4.4810-6 at the first, second and third term.

A more manageable candidate may seem like 32/100, since

1π32100(1-121100-311002+21011002)

with relative errors of approximately 5.410-3,2.810-4,1.810-5,1.610-6 respectively for the first, second, third term, and fourth term. The big nuisance of this building block is that it seems to be built primarily around subtraction rather than addition, something which is harder to manage mentally compared to the “add by shift” of ().

To compare let's try to compute the same 20000/π with the two approximations.

We have 2318=636, so the first two terms of using the 318/1000

20000π=100002π100000.636636=6366.36

(compare with actual result 6366.19772... to show the excellent result of this approximation.)

For 32/100, we have 232=64 and 3×64=252, but:

20000π=100002π10000(0.64-0.0032-0.000252+0.0000128)

that is:

20000π=10000(0.64-0.003452+0.0000128)

and finally:

20000π=6400-34.52+0.128=6365.48+0.128=6365.608

Ultimately, the fact that the expressions in this case are uglier and less manageable may just be the sign that computing the reciprocal of π is an inverse problem. Or that I suck at these kind of things, especially at this hour.