from i to π
1 Attachment(s)
To all math enthusiasts,
this posting describes an amazing method to calculate pi using tetration of imaginary unit i as "baseparameter" [en.wikipedia.org/wiki/Tetration]. Probably this is already common knowledge in the mathematical community, anyhow I could not find concrete information about it. Because mathematical symbols are used inside the formulas, please see attached picture for detailed information. The numerical convergence of this method to calculate pi is rather slowly, in general "heightparameter" [see link above] divided by 20 results (approximately) in the number of correct digits. This has been tested with algorithms for Mathematica and Maple for the concrete "heightparameter" values 200, 500 and 1000 resulting in 10, 25 and 50 correct digits of pi. Calculations were done with computation accuracy of 1000 digits. By the way, calculating the expression (*) without absolute value signs, results in a complex number with real part converging zero and an imaginary part converging pi/2, so absolute value obviously converging pi/2 as stated in the formula. (Please ignore the random number in last line.) Happy new year 2016! 
[QUOTE=stippix;420832]To all math enthusiasts,
this posting describes an amazing method to calculate pi using tetration of imaginary unit i as "baseparameter" [en.wikipedia.org/wiki/Tetration]. Probably this is already common knowledge in the mathematical community, anyhow I could not find concrete information about it. Because mathematical symbols are used inside the formulas, please see attached picture for detailed information. The numerical convergence of this method to calculate pi is rather slowly, in general "heightparameter" [see link above] divided by 20 results (approximately) in the number of correct digits. This has been tested with algorithms for Mathematica and Maple for the concrete "heightparameter" values 200, 500 and 1000 resulting in 10, 25 and 50 correct digits of pi. Calculations were done with computation accuracy of 1000 digits. By the way, calculating the expression (*) without absolute value signs, results in a complex number with real part converging zero and an imaginary part converging pi/2, so absolute value obviously converging pi/2 as stated in the formula. (Please ignore the random number in last line.) Happy new year 2016![/QUOTE] to try to recreate the image for people who don't care to click on it or who may not know about it already): From i to [TEX]\pi[/TEX] using tetration of i ( with[TEX] i^2=1[/TEX]): [TEX]n_i=i\uparrow\uparrow n =i^{i^{i^\ddots}[/TEX] (n times) there is strong numerical evidence of the following result: [TEX]\lim_{n\to\infty} \Bigg(\frac { \frac{{n+1}_in_i}{n_i{n1}_i}}{n_i}\Bigg ) = \frac {\pi}{2}=1.570796...[/TEX] (*) (to be calculated carefully because of numerical extinction) denominator: [TEX]\lim_{n\to\infty} (n_i) = 0.438282... + 0.360592... i [/TEX] and [TEX]\lim_{n\to\infty} (n_i)=0.567555...[/TEX] using Lambert's Wfunction and substitution [TEX]ln(i)=\frac{\pi}{2i}[/TEX] rewriting leads to [en.wikipedia.org/wiki/tetration and wolframalpha.com]: [TEX]\lim_{n\to\infty} (n_i) =\infty_i = \frac{Wln(i)}{ln(i)} =\frac{2i}{\pi} W(\frac{\pi}{2i})=0.438232.. +3.60592...i[/TEX] and [TEX]\lim_{n\to\infty} (n_i)=\infty_i=\ \frac {W(ln(i))}{ln(i)}\=\\frac{2i}{\pi} W(\frac{\pi}{2i})\=0.567555...[/TEX] numerator: if (*) holds analytically rearranging leads to: [TEX]\lim_{n\rightarrow\infty}\Bigg (\frac{{n+1}_i{n_i}}{n_i{n1}_i}\Bigg) = \frac {\pi}{2}\infty_i=\frac{\pi}{2}\frac{W(ln(i))}{ln(i)} = \frac{\pi}{2}\frac{W(ln(i))}{ln(i)}=\frac{\pi}{2} \frac{2i}{\pi} W(\frac{\pi}{2i}) = i W(\frac{\pi}{2i}) = 0.891513...[/TEX] Evaluating [TEX]\frac{0.891513...}{0.567555...}[/TEX] obviously results in 1.570796... again. (*) seems to be an amazing way to calculate [TEX]\pi[/TEX] using tetration of i. redoing this image has added new meaning to what the frac. 
@stippix: I suggest you think first about what you mean by $i^i$. If your answer is $\exp(i \log(i))$ then you need to think about what you mean by $\log(i)$.
From your working, you are using the value $\log(i)=\frac{\pi}{2}i$, in which case you can get $\pi$ from $i$ simply by calculating $2i \log(i)$. We can link $i$ and $\pi$ simply with the equation $e^{i\pi}=1$. If you go on to learn algebraic topology, you will see that the complex numbers together with the exponential function form what is called a covering space for the nonzero complex numbers, and this is the best way of looking at the idea of logarithms on them. 
2 Attachment(s)
Sorry for being offline ... family and holidays ;)
Of course one can use e^(iπ)=−1 to connect i and π, but you cannot calculate π this way numerically, because this does not give you an algorithm to do that. By the way, I would always prefer to write e^(iπ)+1=0, connecting all five important mathematical values 0,1,π,e and i. This is indeed my favourite mathematical formula ... i^i for example results in an real numerical value, i^i^i indeed is a complex number and all higher tetration values also. For more details please have a look into the attached pictures. For me the most relavant result is, that the absolute values of the formulas seem to converge against π/2 as I already mentioned in my starting post. And btw. these tetrations for i look very nice and why shouldn't mathematics be esthetical ... Greetings. 
[QUOTE=stippix;421794]Of course one can use e^(iπ)=−1 to connect i and π, but you cannot calculate π this way numerically, because this does not give you an algorithm to do that.
[/QUOTE]Are you sure of that claim? Remember that e^(ix) = cos(x) + i sin(x)  which is Euler's formula. Then expand e^y as a power series 1 + y +(y^2)/2 + .... +(y^n)/n! + ... Now take the real part of that sum. All the odd powers of y are purely imaginary, so cos(x) = 1 + (x^2)/2! + ... (x^2n)/(2n!) + ... So we can conclude that 1 = cos(π). Now use [URL="http://mathworld.wolfram.com/SeriesReversion.html"]series inversion[/URL] to calculate π The same reasoning could be use for the imaginary part and sin(x). 
I saw an interesting way to calculate pi recently.
Our program calculated random values(uniformly distributed) for x and y between 0 and 1. We calculated whether [TEX]\sqrt{x^2+y^2}[/TEX] was less than 1. This should be true [TEX]100*\pi/4%[/TEX] of the time as we are looking at a quarter circle. This is a rather slow method compared to many out there but it works. You do rely on your random number generator having absolutely no bias etc. 
1 Attachment(s)
Why do you need random numbers? You can just take all grid points and count them, and you make the grid as fine/accurate as you want, and you look how many points are in the circle. "for i=1 to 100; for j=1 to 100...", this also has a known number of steps, and you know when it is finished and the accuracy you will get, and the method guarantees that the points are uniform distributed, and you can make it "fractal", i.e. start with a single point in the middle, which splits the square in 4 parts, add a point in the middle of each, repeat till you have the desired accuracy for the grid/pi you want. You can also exit every time when sqrt>1, and you know how many points you have left, therefore you don't need to compute sqrt's for the full lines (only black dots in the image), which would be even faster.

[QUOTE=LaurV;421883]Why do you need random numbers? You can just take all grid points and count them, and you make the grid as fine/accurate as you want, and you look how many points are in the circle. "for i=1 to 100; for j=1 to 100...", this also has a known number of steps, and you know when it is finished and the accuracy you will get, and the method guarantees that the points are uniform distributed, and you can make it "fractal", i.e. start with a single point in the middle, which splits the square in 4 parts, add a point in the middle of each, repeat till you have the desired accuracy for the grid/pi you want. You can also exit every time when sqrt>1, and you know how many points you have left, therefore you don't need to compute sqrt's for the full lines (only black dots in the image), which would be even faster.[/QUOTE]
True. The point at the time was an example of simulation. 
It just occurred to me that you can use [URL="https://en.wikipedia.org/wiki/Hilbert_curve"]Hilbert's curve[/URL] to count those points, and with few copypastes into a pari/gp window I could get something like: (the parameter x is the number of points on a side, so there are x^2 points):
[code] gp > picnt(10) %27 = 2.760000000000000000000000000 gp > picnt(100) time = 3 ms. %28 = 3.101600000000000000000000000 gp > picnt(200) time = 10 ms. %29 = 3.120700000000000000000000000 gp > picnt(300) time = 25 ms. %30 = 3.127733333333333333333333333 gp > picnt(500) time = 66 ms. %31 = 3.133392000000000000000000000 gp > picnt(1000) time = 290 ms. %32 = 3.137548000000000000000000000 gp > picnt(3000) time = 2,673 ms. %33 = 3.140244000000000000000000000 gp > picnt(5000) time = 7,408 ms. %34 = 3.140787040000000000000000000 gp > picnt(5000) /**/ time = 7,395 ms. %35 = 3.140787360000000000000000000 gp > picnt(10000) time = 30,715 ms. %36 = 3.141190600000000000000000000 gp > picnt(20000) time = 2min, 12,572 ms. %37 = 3.141392160000000000000000000 gp > [/code]Not very fast, and not so accurate either... You may need a million points on a side (which is 10^12 points totally) to get reasonable accuracy and it will take a lot of time... But it [U]is[/U] a method...  ** there are two of 5000 because somewhere in the middle I considered that the two points which are on the circle at (0, max) and (max, 0) should also be included and I changed to return 4*(cnt+2)/(n^2) instead of 4*cnt/(n^2), which seems to improve accuracy. The times differ a bit because the computer was doing other things in the same time. This is single core in a notveryfast laptop. 
A peaceful day for all,
there was a short note about pythagoraic tripples and pi at [url]http://www.maths.surrey.ac.uk/hostedsites/R.Knott/Pythag/pythag.html#section9.6[/url] 2*pi ~ (2^n / amount of primitiv pyth. triples with c=u^2+v^2 < 2^n ) i verified the observation up to n=2^35 2^n = 5. anzahl = 4 ~pi = 4.00000020 2^n = 6. anzahl = 11 ~pi = 2.90909120 2^n = 7. anzahl = 18 ~pi = 3.55555620 2^n = 8. anzahl = 38 ~pi = 3.36842120 2^n = 9. anzahl = 81 ~pi = 3.16049420 2^n = 10. anzahl = 163 ~pi = 3.14110420 2^n = 11. anzahl = 323 ~pi = 3.17027920 2^n = 12. anzahl = 653 ~pi = 3.13629420 2^n = 13. anzahl = 1310 ~pi = 3.12671820 2^n = 14. anzahl = 2607 ~pi = 3.14230920 2^n = 15. anzahl = 5211 ~pi = 3.14411820 2^n = 16. anzahl = 10426 ~pi = 3.14291220 2^n = 17. anzahl = 20863 ~pi = 3.14125520 2^n = 18. anzahl = 41728 ~pi = 3.14110420 2^n = 19. anzahl = 83429 ~pi = 3.14212120 2^n = 20. anzahl = 166871 ~pi = 3.14187620 2^n = 21. anzahl = 333787 ~pi = 3.14145320 2^n = 22. anzahl = 667584 ~pi = 3.14140520 2^n = 23. anzahl = 1335065 ~pi = 3.14164820 2^n = 24. anzahl = 2670147 ~pi = 3.14162820 2^n = 25. anzahl = 5340303 ~pi = 3.14162320 2^n = 26. anzahl = 10680690 ~pi = 3.14159820 2^n = 27. anzahl = 21361461 ~pi = 3.14158620 2^n = 28. anzahl = 42722757 ~pi = 3.14159820 2^n = 29. anzahl = 85445541 ~pi = 3.14159720 2^n = 30. anzahl = 170891241 ~pi = 3.14159420 2^n = 31. anzahl = 341782682 ~pi = 3.14159220 2^n = 32. anzahl = 683565237 ~pi = 3.14159320 2^n = 33. anzahl = 1367130421 ~pi = 3.14159320 2^n = 34. anzahl = 2734261194 ~pi = 3.14159320 2^n = 35. anzahl = 5468521887 ~pi = 3.14159320 Has anybody a good mathematical explication for that ? Greetings from the primes :smile: Bernhard 
It sounds like you're guessing that the density of numbers [$]c=x^2+y^2[/$] with [$]\gcd(x,y)=1[/$] ([url=https://oeis.org/A008784]A008784[/url]) is [$]1/(2\pi)[/$] and you're asking why this is.
But I can't replicate your findings. Up to 2^5, for example, I get {1, 2, 5, 10, 13, 17, 25, 26, 29} with 9 members, not 4. What am I missing? Edit: In fact, the density of A008784 seems to be [$]3/4\pi[/$], or 3/2 times what you found. For example, up to 2^50 I find 268788803404122 terms, giving a density of 0.2387324146[COLOR="DarkRed"]40[/COLOR]... compared to [$]3/4\pi[/$] = 0.2387324146[COLOR="DarkRed"]37[/COLOR].... 
All times are UTC. The time now is 02:13. 
Powered by vBulletin® Version 3.8.11
Copyright ©2000  2022, Jelsoft Enterprises Ltd.