Funny/interesting magic numbers
| hamsterman wrote: |
|---|
| Pi = 1/2*perimeter/radius = 1/2*n*2*sin(Pi/n)*radius / radius = n*sin(Pi/n) ~ Pi So you calculate Pi from Pi, just with less precision. |
This gives me an idea... could I do this recursively, and get greater precision every time?
You could try it. But you can't assume that the algorithm will converge to Pi. You would have to prove that mathematically to be sure (if it is even true). On the other hand, if you just try it, you might find out. You should probably use an arbitrary precision library, rather than
double or something though.
I'll try a library later, I want to use double for now to see if it actually works.
Continued fractions will converge pretty quickly for pi, but Chudnovsky's algorithm converges incredibly fast.
How do you define average radius for a polygon anyways? I think there could be a polygon like that.
| Xander314 wrote: |
|---|
| I doubt you can have a polygon with average radius 1 and side length 1. |
How do you define average radius for a polygon anyways? I think there could be a polygon like that.
| Chudnovsky's algorithm converges incredibly fast. |
Ok then lol. My lecturer lied to me XD
I think we're talking regular polygons here. The first is a square, which has side length 1. As resolution increases, we approach a circle, with "side length 0". So I am guessing side length will decrease.
Average radius is a bit iffy perhaps, but as we approach a circle, it doesn't really matter anyway.
EDIT: Just looked up Chudnovsky's algorithm. I'm actually not sure that's the one my lecturer told me about, but I shan't check now as it's getting late...
Last edited on
If it were up to me I would define a radius of a polygon as the distance from the centroid to a point on a side.
The method of using regular polygons to approximate pi is very bad. I would definitely use something else if I wanted a practical pi generator.
The method of using regular polygons to approximate pi is very bad. I would definitely use something else if I wanted a practical pi generator.
That is the definition of the radius of a polygon. It's the distance from the centroid to any vertex.
The idea of using a polygon to estimate Pi is that the accuracy and precision of your estimation increase as you increase the number of sides. Archimedes used 96 sides and found Pi to 3 digits. A computer could, in theory, use billions of sides and thus calculate Pi to much higher degrees of precision.
The idea of using a polygon to estimate Pi is that the accuracy and precision of your estimation increase as you increase the number of sides. Archimedes used 96 sides and found Pi to 3 digits. A computer could, in theory, use billions of sides and thus calculate Pi to much higher degrees of precision.
Last edited on
But that algorithm is highly unpractical to use when there are others that are much more efficient. Using a 96 sided polygon to get the first three digits is ridiculus when you compare it to continued fractions or Chudnovsky's algorithm.
Here are the convergents of the continued fractions for pi:
3/1 = 3 : one digit
22/7 = 3.142857142... : two digits
333/106 = 3.141509433... : four digits
355/113 = 3.141592920... : six digits
As you can see, continued fractions converge very quickly.
Here are the convergents of the continued fractions for pi:
3/1 = 3 : one digit
22/7 = 3.142857142... : two digits
333/106 = 3.141509433... : four digits
355/113 = 3.141592920... : six digits
As you can see, continued fractions converge very quickly.
| Xander314 wrote: |
|---|
| Ok then lol. My lecturer lied to me XD |
| chrisname wrote: |
|---|
| This gives me an idea... could I do this recursively, and get greater precision every time? |
Last edited on
| He might have been talking about to most simple one |
Yes, when I actually looked at Chudnovsky's algorithm, I realised that wasn't the one I saw. It was in fact the one you linked just now, Leibniz' formula.
| hamsterman wrote: |
|---|
| This method only works when you actually have a polygon and measure it's radius and length of a side with a ruler. |
Why would you do that if you can use math? Human error would account for most of the error with that method. Just try constructing a perfect regular polygon with 96 sides.
Circumference of a circle with diameter 1 = pi
A regular polygon with n sides,
theta = 180/n
sin(theta) = s/(2*.5)
pi = circumference = n*s = n*sin(180/n)
Now use the polynomial expansion of sin, I can't remember what it is off the top of my head though.
My thoughts are a bit unorganized here, sorry.
Edit: My logic might be wrong, I just worked this out off of the top of my head.
sin(x) = x-x3/(3!)+x5/(5!)-...
so...
pi = lim x->infinity(n*(180/n-(180/n)3/(3!)+(180/n)5/(5!)-...))
= 180
crap, I forgot that you have to use radians for derivatives of trig functions, so actually...
pi = lim x->infinity(n*(pi/n-(pi/n)3/(3!)+(pi/n)5/(5!)-...))
= pi.
So there you have it, a method to approximate pi.
Edit: But wait, I'm using pi to calculate pi? That's defining a word using the word being defined. Anyone have better ideas?
Last edited on
http://en.wikipedia.org/wiki/Approximations_of_pi
A little down the page:
It's only accurate to 16 digits.
A little down the page:
| He achieved this level of accuracy by calculating the perimeter of a regular polygon with 3 × 2×1018 sides. |
It's only accurate to 16 digits.
| But wait, I'm using pi to calculate pi? |
| Anyone have better ideas? |
| hamsterman wrote: | |
|---|---|
My point exactly. |
That's why I asked if doing it again would get greater precision. I couldn't see that working, it seems like it disobeys the law of conservation of energy; although in this case it would be more like conservation of precision.
When you say PI, do you mean the decimal numbers in PI, or actual binary numbers of PI?