Talk:Machin-like formula
This article is rated Start-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | |||||||||||
|
Efficiency
[edit]The Efficiency section ignores that the time needed for multiplication and division often increases with the size of the multiplier or divisor. As some of the times shown are not so different for the different series, it is easily possible that some that are claimed faster are actually slower. (Not to mention the additional time debugging some series.) Gah4 (talk) 09:10, 29 October 2015 (UTC)
This page focuses on the theoretical efficiency of these formulae, not the actual complexities in implementing them in pi-calculating programs. If you wish to discuss these topics, I suggest you create a separate page, or expand on the "Approximations of Pi" page. — Preceding unsigned comment added by 202.212.253.67 (talk) 01:03, 10 February 2017 (UTC)
- I suppose so. At the time, I was doing it on an IBM 360/20, one of the slower machines one would ever try. In most cases, there is a discontinuity in the time when the divisor gets bigger than a machine dependent value, usually related to the machine word size. In my case, the divisor could only be up to 15 decimal digits. Even more, though, for the 360/20 the time for doing division depends on the number of decimal digits in the divisor. A quick calculation showed that one that the theory showed would be faster, was going to be slower on the machine I had available. Gah4 (talk) 02:15, 10 February 2017 (UTC)
Note
[edit]Note that the origin is called C in the diagram. The letter O in the diagram refers to the point (1,1). — Preceding unsigned comment added by 86.134.223.175 (talk) 08:16, 7 July 2016 (UTC)
Other Formula by Euler
[edit]Wikipedia itself notes elsewhere another formula for π/4 attributed to Leaonard Euler:
- π/4 = 5 atan(1/7) + 2 atan(3/79) Computing π
I guess it also matches the schema and could be further of historical interest. Jan Burse (talk) 21:17, 15 February 2017 (UTC)
I believe that this particular formula is indeed of some historical interest and I would encourage you to add it. It's only since the dawn of the computer age that anybody sets to anything other than one. The formula you have cited is a rare exception, and is therefore noteworthy.
There are two equations frequently attributed to Euler:
The former has an estimated runtime of 7.0588, and the latter has an estimated runtime of 2.7646 . The latter is clearly faster. Does that make it better? We already cite the former version. Shouldn't we also cite the version that is known to be better?
There are other web pages that list thousands of formula variations. I maintain that the Wikipedia page should limit itself to just a handul of variations, those that are somehow noteworthy. I believe that the equation you have cited qualifies for this.
The question is, where should it go? I'm thinking right next to equation 5, but that's up to you.
I have often wondered why the Wikipedia page doesn't cite the following equation:
It too is a rare exception, and is therefore noteworthy. Shouldn't we have at least one example where is something other than one? If I might answer my own question, it's because this equation is merely a trivial re-combination of two other well known equations:
The former is Hermann's. The latter is the version of Euler that you have cited.
I would like to see the community discuss this issue more. What equations are noteworthy enough to be added to the Wikipedia page? We should come to a concensus as to what the rules are. Permit me to propose:
- 1. The equation is of some historical significance. Or,
- 2. At the time the equation was discovered, it was the fastest equation known.
The problem with the latter is that brought up by Gah4. Many of the equations we have cited are theoretically very fast, but due to the extreme size of they require the use of synthetic arithmetic. Smwolfe (talk) 18:52, 18 February 2017 (UTC)
- just for fun I compared the different formulas in a finite sum approximation of integ 1/(1+x^2) dx, the Euler one is also better than the plain one:
- sum_k=0^(n-1) (4.0 1/(1+(k/n)^2) 1/n) at n=128
- = 3.14939
- sum_k=0^(n-1) (20.0 1/(1+(1/7 k/n)^2) 1/7 1/n + 8.0 1/(1+(3/79 k/n)^2) 3/79 1/n) at n=128
- = 3.14182
- Jan Burse (talk) 20:48, 29 July 2019 (UTC)
- Since the Ruby programming language in their BigDecimal package uses the classical
- machin formula, here a comparison with Euler, using Lehmer's measure after the ~~>:
- ~~> 3.07736791...
- ~~> 2.26560388...
- Jan Burse (talk) 01:39, 30 August 2022 (UTC)
The one-term formula
[edit]The reasoning on the article page seems to indicate that using the well-known single-term formula
- π/4 = arctan 1
would take infinitely long to compute, since a1/b1 is 1 in this case, which implies that its logarithm, which stands in the denominator, is zero.
The Taylor/Maclaurin series becomes then
- arctan 1 = 1 - 1/3 + 1/5 - 1/7 + 1/9 ...
a series which of course converges, albeit slowly, but I wouldn't say infinitely slowly.
Maybe the article ought to mention this particular Machin-like formula (where c0 = c1 = a1 = b1 = N = 1) as a "worst case" against which all other cases should be compared. — Tonymec (talk) 23:36, 4 August 2017 (UTC)
The problem is that the power series for arctan 1 is at the edge of convergence ( does not converge). The rough estimate for the correct digits uses an estimate against a geometric series, which doesn't work in this case. So it is not infinitley slow, but in an totally different speed class (the error is less than 1/2N after N Terms, compared to (a/b)^2N if a/b<1).LamaMaddam (talk) 14:42, 12 March 2020 (UTC)
- I haven't thought about it for a while, but I think the number of digits is O(log N). I suspect that the article should mention it, but I also believe that is isn't a Machin-like formula. That is, for the same reason that 1 isn't a prime number. Reminds me, when I first learned about the harmonic series not converging, I started a sum on my HP25C (so you can figure out when that was) and let it run a few days. Gah4 (talk) 15:00, 12 March 2020 (UTC)
At the very beginning of the article, it says "Machin-like formulas have the form … where … an < bn". Given this as the definition, arctan(1/1) would not be considered a valid formula. Smwolfe (talk) 16:09, 12 March 2020 (UTC)
Efficiency: missing penalty for huge numerators
[edit]As far as I can see the fraction is estimated to perform exactly the same way as the fraction , namely It's true that the number of required terms for achieving a certain accuracy is exactly the same, but the calculation of involves about 30 times as many decimal digits compared to . –Nomen4Omen (talk) 17:23, 18 December 2020 (UTC)
- It is not so easy to figure out the times. In the case of a power series expansion, the important calculation is from one term to the next, which in the cases shown is mostly dividing by . If that fits in a machine word, then the division is fairly simple. If is not one, then at each step you also multiply by . Also, as I previously noted, on some machines the speed of multiply and divide are dependent on the actual numbers. (Many special-case multiply by zero, for example.) Note even more, that the calculations are most often done in binary, unless the machine is faster in decimal. (The IBM 360/20 has decimal divide but not binary divide.) Gah4 (talk) 22:56, 18 December 2020 (UTC)
- I agree: It is not so easy to figure out the times. And even if we concentrate on really big machines and calculations which blast the size of the machine word – i.e. concentrate on algorithms for multiple word integers –, it is not so easy. But also in this case the number of digits of an operand (its „length“) should contribute (about linearly?, quadratically?) to the running time – and I cannot see this to be reflected in the considerations of the §, because is ALWAYS accompanied by either in the form or or and never in the form or –Nomen4Omen (talk) 11:20, 19 December 2020 (UTC)
- OK, first, calculations are always done in fixed point. Integers after moving the radix point appropriately. Now you want to do arithmetic on multiple word values. To add such values, go right to left, add, if there is overflow add one to the value to the left. (Like you learn in first grade, except the digits are now much bigger.) For divide by a value that fits in a machine word: start on the left and divide. Replace the value with the quotient. Put the remainder to the left of the next word to the right and continue to the right. This, in the general case, requres a divide with a double length dividend. Most hardware provides this, most high-level languages do not. Doing it in a high-level language, then, requires one to use a "word" size half the available size. In any case, as long as the divisor fits into the appropriate size, such as a machine word, it is easy to do, and linear in the number of words in the multiple word value. Gah4 (talk) 19:44, 19 December 2020 (UTC)
- If I understand you correctly this means an additional factor of –Nomen4Omen (talk) 19:50, 19 December 2020 (UTC)
- Well, it might be more like That is, log base 4294967296. So, as long as and aren't so big, there is no extra factor. Gah4 (talk) 00:50, 20 December 2020 (UTC)
- If I understand you correctly this means an additional factor of –Nomen4Omen (talk) 19:50, 19 December 2020 (UTC)
- OK, first, calculations are always done in fixed point. Integers after moving the radix point appropriately. Now you want to do arithmetic on multiple word values. To add such values, go right to left, add, if there is overflow add one to the value to the left. (Like you learn in first grade, except the digits are now much bigger.) For divide by a value that fits in a machine word: start on the left and divide. Replace the value with the quotient. Put the remainder to the left of the next word to the right and continue to the right. This, in the general case, requres a divide with a double length dividend. Most hardware provides this, most high-level languages do not. Doing it in a high-level language, then, requires one to use a "word" size half the available size. In any case, as long as the divisor fits into the appropriate size, such as a machine word, it is easy to do, and linear in the number of words in the multiple word value. Gah4 (talk) 19:44, 19 December 2020 (UTC)
- I agree: It is not so easy to figure out the times. And even if we concentrate on really big machines and calculations which blast the size of the machine word – i.e. concentrate on algorithms for multiple word integers –, it is not so easy. But also in this case the number of digits of an operand (its „length“) should contribute (about linearly?, quadratically?) to the running time – and I cannot see this to be reflected in the considerations of the §, because is ALWAYS accompanied by either in the form or or and never in the form or –Nomen4Omen (talk) 11:20, 19 December 2020 (UTC)
- If you mean I agree 100 %. –Nomen4Omen (talk) 10:28, 20 December 2020 (UTC)
Misattribution of the formula starting with arctan(1/390112)
[edit]It was found 1993, not by Hwang Chien-Lih, but by me. See Figure 32.5-C on page 635 in the book "Matters Computational", see https://jjj.de/fxt/#fxtbook. Due to the obvious conflict of interest I will not touch the page. The material in https://jjj.de/arctan/arctanpage.html should still reflect the present state of affairs. - Joerg Uwe Arndt (talk) 11:08, 8 June 2021 (UTC)
- I'm sure you do not mean 1/390122. So I corrected that in the heading.
- The text talks about a formula pair. So it may well be that it's you who found the first (and important) part, but Hwang Chien-Lih may have found the pairing. I have tried to separate the 2 formulas. −Nomen4Omen (talk) 15:14, 8 June 2021 (UTC)
- About checking pairs: the checking pair for the 11-term formula is not in my fxtbook, but neither is it in the Gazette article. Finding such pairs for n-term formulas with n>=3 is easy because there are more and more (inverse) arguments for the set of primes used. What I seem to have done (stopping at 10-term relations) is shown in Figure 32.5-E on page 637 in the fxtbook. - Joerg Uwe Arndt (talk) 15:42, 8 June 2021 (UTC)
- I'll also try to enter a reference of yours into the article. −Nomen4Omen (talk) 08:10, 9 June 2021 (UTC)
Efficiency revisited: missing penalty for huge numerators
[edit]Nobody seems to care about this issue, all contributors measure a term proportional to , so Lehmer in Machin-like formula#Lehmer's measure and Smwolfe who entered the section Machin-like formula#Efficiency on 13:02, 10 March 2013 (although the latter defines if and if , so there is a tiny penalty). But there exist formulas with huge numerator :
It is easy to find for every a two-term formula
- ,
namely
- .
Depending on can be chosen such that
- .
Furthermore, can be chosen sufficiently large, so that and its cost is infinitesimal. If then the cost of is counted proportional to the total cost can be made infinitesimal, because –Nomen4Omen (talk) 10:02, 19 October 2021 (UTC)
New Notable Formula?
[edit]Now it makes me think the alternativ Leonhard Euler formula isn't notable, since it doesn't beat John Machine. Just found this gem by Xavier Gourdon, in parenthesis the Lehmer measure (using natural logarithm):
- Leonhard Euler: π = 20*atan(1/7)+8*atan(3/79) (0.8196306179594626)
- John Machine 1706: π = 16*atan(1/5)+ -4*atan(1/239) (0.8039345246997319)
- ? Xavier Gourdon 2001 ?: π = 20*atan(29/278)+28*atan(3/79) (0.7481464746474802)
What is the origin of the last formula? I found it here: http://numbers.computation.free.fr/Constants/PiProgram/Pi_Rational.pifast But likely there are other 2 summand formulas with a lower Lehmer mesaure? How would it be notable, other constraint among the summands?
- Interesting, looks like the formula 20*atan(29/278)+28*atan(3/79) is from James Thomson, reported 1839, or possibly known already for longer. Also the formula 88*atan(24478/873121)+68*atan(685601/69049993) is found there:
- XI. Investigation of a New Series for the Computation of Logarithms ; with a New Investigation of a Series for the Rectification of the Circle. By JAMES Thomson, LL.D., Professor of Mathematics in the University of Glasgow.
- in Transactions of the Royal Society of Edinburgh, Band 14,Ausgabe 1
- https://books.google.ch/books?id=f0ED_CKR6AsC&lpg=PA223&ots=T9XjaJnuiD&dq=69049993&hl=de&pg=PA223#v=onepage&q=69049993&f=false
Jan Burse (talk) 14:34, 15 November 2022 (UTC)
Verification of Formula
[edit]I am surprised that verification of a formula seems to be a challenge. In order to verify that
we can apply tan to both sides of the equation.
If
then for a specific k Z (in this case k = 0)
In order to compute tan(m arctan a/b) we consider the binary representation of m
compute tan(2i arctan a/b) for all 0 ≤ i ≤ n by applying
and (recursively)
and determine tan( ci 2i arctan a/b) by applying tan(x+y) = tan x + tan y/1-tan x tan y .
If
then
In order to save one multiplication we compute
as
Many intermediate results can be simplified by dividing numerator and denominator by their greatest common divisor, but integer division is more time consuming than integer multiplication, and the computation of the greatest common divisor is even more time consuming.
In this way, running a simple JAVA program using JAVA's BigInteger class
Hwang Chien-Lih's formula from 2004 can be verified in a few seconds.
Even Jörg Uwe Arndt's formula from 1993 with greater coefficients can be verified in less than a minute. D6yn63t8yi (talk) 12:50, 31 March 2024 (UTC)
- These formulas are all trivial to verify using the tangent addition identity:
- Or if you prefer,
- –jacobolus (t) 14:45, 31 March 2024 (UTC)