How do I calculate PI in C#?

Question

How can I calculate the value of PI using C#?

I was thinking it would be through a recursive function, if so, what would it look like and are there any math equations to back it up?

I'm not too fussy about performance, mainly how to go about it from a learning point of view.

Answer 1

Calculate like this:

x = 1 - 1/3 + 1/5 - 1/7 + 1/9  (... etc as far as possible.)
PI = x * 4

You have got Pi !!!

This is the simplest method I know of.

The value of PI slowly converges to the actual value of Pi (3.141592165......). If you iterate more times, the better.

Answer 2

Enumerable.Range(0, 100000000).Aggregate(0d, (tot, next) => tot += Math.Pow(-1d, next)/(2*next + 1)*4)

Answer 3

The following link shows how to calculate the pi constant based on its definition as an integral, that can be written as a limit of a summation, it's very interesting: https://sites.google.com/site/rcorcs/posts/calculatingthepiconstant The file "Pi as an integral" explains this method used in this post.

Answer 4

There are a couple of really, really old tricks I'm surprised to not see here.

atan(1) == PI/4, so an old chestnut when a trustworthy arc-tangent function is present is 4*atan(1).

A very cute, fixed-ratio estimate that makes the old Western 22/7 look like dirt is 355/113, which is good to several decimal places (at least three or four, I think). In some cases, this is even good enough for integer arithmetic: multiply by 355 then divide by 113.

355/113 is also easy to commit to memory (for some people anyway): count one, one, three, three, five, five and remember that you're naming the digits in the denominator and numerator (if you forget which triplet goes on top, a microsecond's thought is usually going to straighten it out).

Note that 22/7 gives you: 3.14285714, which is wrong at the thousandths.

355/113 gives you 3.14159292 which isn't wrong until the ten-millionths.

Acc. to /usr/include/math.h on my box, M_PI is #define'd as: 3.14159265358979323846 which is probably good out as far as it goes.

The lesson you get from estimating PI is that there are lots of ways of doing it, none will ever be perfect, and you have to sort them out by intended use.

355/113 is an old Chinese estimate, and I believe it pre-dates 22/7 by many years. It was taught me by a physics professor when I was an undergrad.

Answer 5

    public static string PiNumberFinder(int digitNumber)
    {
        string piNumber = "3,";
        int dividedBy = 11080585;
        int divisor = 78256779;
        int result;

        for (int i = 0; i < digitNumber; i++)
        {
            if (dividedBy < divisor)
                dividedBy *= 10;

            result = dividedBy / divisor;

            string resultString = result.ToString();
            piNumber += resultString;

            dividedBy = dividedBy - divisor * result;
        }

        return piNumber;
    }

Answer 6

@Thomas Kammeyer:

Note that Atan(1.0) is quite often hardcoded, so 4*Atan(1.0) is not really an 'algorithm' if you're calling a library Atan function (an quite a few already suggested indeed proceed by replacing Atan(x) by a series (or infinite product) for it, then evaluating it at x=1.

Also, there are very few cases where you'd need pi at more precision than a few tens of bits (which can be easily hardcoded!). I've worked on applications in mathematics where, to compute some (quite complicated) mathematical objects (which were polynomial with integer coefficients), I had to do arithmetic on real and complex numbers (including computing pi) with a precision of up to a few million bits... but this is not very frequent 'in real life' :)

You can look up the following example code.