Pi approximation games

On May 2, 3:44=A0pm, Syd Rumpo <use...@neonica.co.uk> wrote:
> On 02/05/2012 16:20, George Herold wrote:
>
> <snip>
>
> > Grin... I always just let 2*pi =3D 10, so pi =3D 5!
>
> That's known as a 'Selleck' or a 'Magnum PI'.
>
> Cheers
> --
> Syd

Chuckle... That's great...

I was thinking that most of the time I let 1/2pi =3D 1.6/10  or pi =3D 10
x 5/16 which is better than 1%.

 George H.

In comp.dsp VWWall <vwall@large.invalid> wrote:

(snip, I wrote)
>> One involves a more accurate determination of Avogadro's number.
 
> Avogadro's number is currently: 6.02214129*10^23 entities per mole and 
> has an uncertainty of plus or minus 27 counts in its last two digits.

The ongoing project involves weighing and counting the number
of atoms in a silicon sphere. When you figure out how many are
in a kg, that could be, should be, an integer.

-- glen

pi/4 = 1 - 1/3 + 1/5 - 1/7 + ...

pi/4 = Sum [(-1)^p]/(2p+1)  p = 0 to oo

max error =|[((-1)^p)/(2p+1)]-[(-1)^(p+1)]/(2(p+1)+1)|

for instance if I want to calculate pi to the nearest E = +/- 10^-50, the 
series will have to be carried out p times such that

10^-50 = |1/(2p+1)-1/(2p+3)|

E(2p+3)(2p+1)=(2p+3) - (2p+1)

E(4p^2 + 8p + 3) = 2

4p^2 + 8p + (3 - 2/E) = 0

p = (-2 +/-{4-(3-2/E)}^.5)/2

for E = 10^-50, p = 10^25

for E = 1/2^128 , p = 10^20 

On 5/2/12 4:29 PM, David Drumm wrote:
> I wonder if there's a theorem that states: given a small positive number
> epsilon, there exists a rational number that is within epsilon to pi.

that is the case for any real number.  rational or irrational.

-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

On May 2, 1:16=A0am, Tim Wescott <t...@seemywebsite.com> wrote:
> Instead of doing productive work, I just spent a few enjoyable minutes
> with Scilab finding approximations to pi of the form m/n.
>
> Because I'm posting to a couple of nerd groups, I can be confident that
> most of you probably know 22/7 off the tops of your heads.
>
> What interested me is how spotty things are -- after 22/7, the error
> drops for a bit until you get down to 355/113 (which, if you're at an
> equal level of nerdiness to me will ring a bell, but not have been
> swimming around in your brain to be found).
>
> But what's _really_ interesting, is that the next better fit isn't found
> until you get up to52163/16604. =A0Then things get steadily better until
> you hit 104348/33215 -- at which point the next lowest ratio which
> improves anything is 208341/66317, then 312689/99532. =A0At this point I
> decided that I would post my answers for your amusement, and get back to
> being productive.
>
> Discrete math is so fun. =A0And these newfangled chips are just destroyin=
g
> the joy, by making floating point efficient and cheap enough that you
> don't need to know little tricks like pi =3D (almost) 355/113.
>
> --
> My liberal friends think I'm a conservative kook.
> My conservative friends think I'm a liberal kook.
> Why am I not happy that they have found common ground?
>
> Tim Wescott, Communications, Control, Circuits & Softwarehttp://www.wesco=
ttdesign.com

I've recently discovered a program called Wolfram Alpha. If you have
an obsessive interest in series expansions, you can spend hours with
this program.

Bob

On May 3, 4:18=A0am, VWWall <vw...@large.invalid> wrote:
> Nico Coesel wrote:
> > spop...@speedymail.org (Steve Pope) wrote:
>
> >> John Devereux =A0<j...@devereux.me.uk> wrote:
>
> >>> John S <Soph...@invalid.org> writes:
> >>>> I like the idea that both 22 and 7 each fit into a byte whereas 355
> >>>> does not. And, 22/7 is hi by only .04%. Beautiful!
> >>> We had a teacher that insisted it was exactly equal!
> >> I recall the time when you couldn't consider 25.4 mm to be exactly
> >> one inch. =A0But, they fudged enough standards so that it is now exact=
.
>
> >> Prior to that, neither the British inch nor the American inch
> >> measures 25.4 ... and they deviated from that value in opposite
> >> direction!
>
> > So you are saying the inch is in fact metric?
>
> See:http://www.unc.edu/~rowlett/units/index.html
>
> "Meanwhile, only a few Americans know that the legal definitions of the
> English customary units are actually based on metric units. The U. S.
> and British governments have agreed that a yard equals exactly 0.9144
> meter and an avoirdupois pound equals exactly 0.453 592 37 kilograms. In
> this way, all the units of measurement Americans use every day are based
> on the standards of the metric system. Since 1875, in fact, the United
> States has subscribed to the International System of Weights and
> Measures, the official version of the metric system."
>
> --
> Virg Wall, P.E.

That's the British customary units, not English, that's the language
you are confusing with the country which is Great Britain. another
common mishtake made by americans.

On 02/05/2012 17:32, Uwe Hercksen wrote:
>
>
> David Brown schrieb:
>
>> <http://en.wikipedia.org/wiki/Lazy_evaluation>
>>
>> The most relevant section, "working with infinite data structures", is
>> missing - but I hope you get the point anyway.
>
> Hello,
>
> even with infinite data structures, with finite time and finite RAM, it
> is not possible to compute all digits of pi.
>
> Bye
>

Calculate pi using "infinite precision" numbers, and you get it to 
infinite precision.  Obviously you can't print out the whole answer - 
but you can print out as much of the answer as you want, until the 
machine runs out of memory or time.

An "infinite precision number" is usually held as a list of digits, 
along with a method for calculating more digits.  You can then write 
functions that can add, subtract, multiply and divide such numbers.  It 
is particularly convenient to use a functional programming language for 
such tasks, as they are good at working with unlimited lists, and with 
manipulating functions (such as the digit generator function).

To calculate pi, the easiest way is to note that atan(1) = pi/4, and 
atan(x) = x - x^3 / 3 + x^5 / 5 - x^7 / 7 + ...  Once you have the 
individual parts in place, the rest is easy.  Of course, you end up with 
lots of unlimited lists of unlimited lists, etc.

Mathematically speaking, what you have is precise representation of 
/all/ the digits of pi.  You can't display them all, as you have limited 
ram and time - but it /is/ precise and contains /all/ the digits - just 
as "0.33..." is a precise decimal representation of /all/ the digits of 
1/3 (the "..." gives the method of producing any digits you want).

On 03/05/2012 08:40, David Brown wrote:
> On 02/05/2012 17:32, Uwe Hercksen wrote:
>>
>>
>> David Brown schrieb:
>>
>>> <http://en.wikipedia.org/wiki/Lazy_evaluation>
>>>
>>> The most relevant section, "working with infinite data structures", is
>>> missing - but I hope you get the point anyway.
>>
>> Hello,
>>
>> even with infinite data structures, with finite time and finite RAM, it
>> is not possible to compute all digits of pi.
>>
>> Bye
>>
>
> Calculate pi using "infinite precision" numbers, and you get it to
> infinite precision. Obviously you can't print out the whole answer - but
> you can print out as much of the answer as you want, until the machine
> runs out of memory or time.

But that isn't how the trick was done. There is a cute expression for 
the Nth hexadecimal digit representation of pi detailed at:

http://crd-legacy.lbl.gov/~dhbailey/pi/pi-alg
>
> An "infinite precision number" is usually held as a list of digits,
> along with a method for calculating more digits. You can then write
> functions that can add, subtract, multiply and divide such numbers. It
> is particularly convenient to use a functional programming language for
> such tasks, as they are good at working with unlimited lists, and with
> manipulating functions (such as the digit generator function).
>
> To calculate pi, the easiest way is to note that atan(1) = pi/4, and
> atan(x) = x - x^3 / 3 + x^5 / 5 - x^7 / 7 + ... Once you have the
> individual parts in place, the rest is easy. Of course, you end up with
> lots of unlimited lists of unlimited lists, etc.

No-one in their right mind would start from that crude series today - 
its convergence for x=1 is absolutely hopeless. See for example:

http://en.wikipedia.org/wiki/Pi#Infinite_series

> Mathematically speaking, what you have is precise representation of
> /all/ the digits of pi. You can't display them all, as you have limited
> ram and time - but it /is/ precise and contains /all/ the digits - just
> as "0.33..." is a precise decimal representation of /all/ the digits of
> 1/3 (the "..." gives the method of producing any digits you want).

The algorithm that can supply the Nth digits of pi lazily *only* works 
for hexadecimal digits (or base 2^N for certain N).

It doesn't work at all for the *decimal* representation of pi.

-- 
Regards,
Martin Brown

On 2012-05-02, John Devereux <john@devereux.me.uk> wrote:
> spope33@speedymail.org (Steve Pope) writes:
>
>> John Devereux  <john@devereux.me.uk> wrote:
>>
>>>John S <Sophi.2@invalid.org> writes:
>>
>>>> I like the idea that both 22 and 7 each fit into a byte whereas 355
>>>> does not. And, 22/7 is hi by only .04%. Beautiful!
>>>
>>>We had a teacher that insisted it was exactly equal!
>>
>> I recall the time when you couldn't consider 25.4 mm to be exactly
>> one inch.  But, they fudged enough standards so that it is now exact.
>
> Aha, good idea, we should standardize pi to a more convenient value! :)
>
> (Didn't they already try that?)
>
>> Prior to that, neither the British inch nor the American inch
>> measures 25.4 ... and they deviated from that value in opposite
>> direction!
>
> I suppose the american inch was bigger...
>

I have in my hands an "Nelson's Encyclopedia"  printed in 1951 (12
years before the international inch) it says the metre (then
defined by scratches on a bar in Paris) is is about 1.0936143 yards
(then defined by scratches on a bar in London) 

 1 / 36 / 1.0936143  comes to .025399977m

so, yes the American inch was the bigger of the two.



-- 
&#9858;&#9859; 100% natural

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

On 03/05/2012 09:55, Martin Brown wrote:
> On 03/05/2012 08:40, David Brown wrote:
>> On 02/05/2012 17:32, Uwe Hercksen wrote:
>>>
>>>
>>> David Brown schrieb:
>>>
>>>> <http://en.wikipedia.org/wiki/Lazy_evaluation>
>>>>
>>>> The most relevant section, "working with infinite data structures", is
>>>> missing - but I hope you get the point anyway.
>>>
>>> Hello,
>>>
>>> even with infinite data structures, with finite time and finite RAM, it
>>> is not possible to compute all digits of pi.
>>>
>>> Bye
>>>
>>
>> Calculate pi using "infinite precision" numbers, and you get it to
>> infinite precision. Obviously you can't print out the whole answer - but
>> you can print out as much of the answer as you want, until the machine
>> runs out of memory or time.
>
> But that isn't how the trick was done. There is a cute expression for
> the Nth hexadecimal digit representation of pi detailed at:
>

I think you missed the earlier post in which I said that I /did/ do 
this, as a project at university.  There may be other ways to calculate 
pi that are more efficient in base 16 - but that's a different matter 
entirely.

> http://crd-legacy.lbl.gov/~dhbailey/pi/pi-alg
>>
>> An "infinite precision number" is usually held as a list of digits,
>> along with a method for calculating more digits. You can then write
>> functions that can add, subtract, multiply and divide such numbers. It
>> is particularly convenient to use a functional programming language for
>> such tasks, as they are good at working with unlimited lists, and with
>> manipulating functions (such as the digit generator function).
>>
>> To calculate pi, the easiest way is to note that atan(1) = pi/4, and
>> atan(x) = x - x^3 / 3 + x^5 / 5 - x^7 / 7 + ... Once you have the
>> individual parts in place, the rest is easy. Of course, you end up with
>> lots of unlimited lists of unlimited lists, etc.
>
> No-one in their right mind would start from that crude series today -
> its convergence for x=1 is absolutely hopeless. See for example:
>
> http://en.wikipedia.org/wiki/Pi#Infinite_series

As I said, it was a university project.  The aim was not to calculate 
pi, but to understand the usage of infinite lists, infinite precision 
numbers, ways to manipulate them, and ways to prove that the code to do 
so is correct.  The rate of convergence is utterly irrelevant.

Just for fun, I figured out an alternative series that was faster to 
converge (possibly (atan(1/2) + atan(1/3)), though I can't remember for 
sure).

>
>> Mathematically speaking, what you have is precise representation of
>> /all/ the digits of pi. You can't display them all, as you have limited
>> ram and time - but it /is/ precise and contains /all/ the digits - just
>> as "0.33..." is a precise decimal representation of /all/ the digits of
>> 1/3 (the "..." gives the method of producing any digits you want).
>
> The algorithm that can supply the Nth digits of pi lazily *only* works
> for hexadecimal digits (or base 2^N for certain N).
>
> It doesn't work at all for the *decimal* representation of pi.
>

Nonsense.  I did it, and I didn't find it particularly hard.

Perhaps you misunderstand what "lazy evaluation" actually is.  The 
algorithm you reference is a way to calculate a hexadecimal digit of pi 
without having to calculate the previous digits - no such method is 
known for calculating the decimal digits (though that does not mean one 
does not exist).  But that has nothing at all to do with lazy 
evaluation, which simply means that the relevant numbers are calculated 
when needed rather than in advance.  It means you can work with an 
unlimited list, and treat it as though it were a fully calculated 
infinite list, without the computer actually having to calculate 
anything until the last minute.