Calculate Pi

[d&q]

Here's a way to calculate pi without using the stored pi constant..

This is using the Leibniz formula for pi(takes a large n to converge I believe)

Code: [Select]

public class Pi
{
    public static void main(String[] args)
    {
        //A larger n will give a closer approximation
        int n = 6000000;
        double x = 0;
       
        for(int i = 0; i < n; i++)
        {
            x += Math.pow(-1, i)/(2*i + 1);
        }
        System.out.println(x*4);
    }
}

[AntiVirus]

Cool cool.  I personally make sure that if I declare something a float or double I make sure there is a decimal in it. 

Code: [Select]

double x = 0.00;
Just a suggestion.  And since this is a very small program it doesn't really matter, but you should try and conserve the amount of memory you use.  The double takes up twice as much memory as a float (if this was a large program and that variable was used a lot, it would show).

Aside from those miner details, it looks good.  I haven't checked to see if the answer is right, but I trust you have. 

[Rule]

Cool cool.  I personally make sure that if I declare something a float or double I make sure there is a decimal in it. 

Code: [Select]

double x = 0.00;
Just a suggestion.  And since this is a very small program it doesn't really matter, but you should try and conserve the amount of memory you use.  The double takes up twice as much memory as a float (if this was a large program and that variable was used a lot, it would show).

Aside from those miner details, it looks good.  I haven't checked to see if the answer is right, but I trust you have. 

lol. This is such an "I just finished an introductory course in programming" response. 

[Sidoh]

The inclusion of the decimal is irrelevant.  You're explicitly declaring it as something with decimal precision (double).  The only time it's important to use decimals is when you want to (implicitly, lazily) determine the datatype of the result (ie 1.0/10.0 is 0.1, but 1/10 is (an integer) 0).

In addition, I'm pretty sure that you wouldn't want to use anything other than a double for a calculation that can (potentially) have an infinite number of digits.  When you're calculating Pi in this sort of way, you want to use the most accurate datatype possible, which is double (without making inventing your own or implementing some other one).  I don't think double and float have the same number of bytes allocated for the mantissa, in which case the double would almost surely have more.

lol. This is such an "I just finished an introductory course in programming" response. 

lol, I thought that as well, but I'm pretty sure most of the suggestions are on fallacious grounds.

[AntiVirus]

Cool cool.  I personally make sure that if I declare something a float or double I make sure there is a decimal in it. 

Code: [Select]

double x = 0.00;
Just a suggestion.  And since this is a very small program it doesn't really matter, but you should try and conserve the amount of memory you use.  The double takes up twice as much memory as a float (if this was a large program and that variable was used a lot, it would show).

Aside from those miner details, it looks good.  I haven't checked to see if the answer is right, but I trust you have. 

lol. This is such an "I just finished an introductory course in programming" response. 

I fail to see why that matters?  It shouldn't matter where I am in my programming career.  My post's intent was to help him learn. 

The inclusion of the decimal is irrelevant.  You're explicitly declaring it as something with decimal precision (double).  The only time it's important to use decimals is when you want to (implicitly, lazily) determine the datatype of the result (ie 1.0/10.0 is 0.1, but 1/10 is (an integer) 0).

I am aware of that, Sidoh.  I was just saying what I like to do.  I didn't say that it was manditory. 

In addition, I'm pretty sure that you wouldn't want to use anything other than a double for a calculation that can (potentially) have an infinite number of digits.  When you're calculating Pi in this sort of way, you want to use the most accurate datatype possible, which is double.  I don't think double and float have the same number of bytes allocated for the mantissa, in which case the double would almost surely have more.

You're completely right, Sidoh.  I over looked

Code: [Select]

x += Math.pow(-1, i)/(2*i + 1);.  My mistake.

[Rule]

lol, I thought that as well, but I'm pretty sure most of the suggestions are on fallacious grounds.

Yeah, I agree.  The double is more appropriate here, and adding decimal places is kind of silly.  There is no ambiguity if you declare the datatype as double or float. 

Antivirus:
I don't care where you are, but you sounded so 'sophomoric' if that is the correct word.  It's like you had a big label on your forehead that said NOVICE.  I recognized what you were saying as stuff that they told us when we first started programming, and then never heard again later.

In practice, if you aren't sure whether to make a variable a float or a double, make it a double.  There are instances where you would want to use a float, but it's not going to matter if there are floats that are scattered about as single variables, even in large programs.  It will only make a difference if you say, want to declare a real valued 4 dimensional array of 100x100x100x100, or something like that.

However, I believe this algorithm takes a long time to converge to more than 6 correct decimal places (over a day, at least?)

[Sidoh]

Yeah, I agree.  The double is more appropriate here, and adding decimal places is kind of silly.  There is no ambiguity if you declare the datatype as double or float. 

Antivirus:
I don't care where you are, but you sounded so 'sophomoric' if that is the correct word.  It's like you had a big label on your forehead that said NOVICE.  I recognized what you were saying as stuff that they told us when we first started programming, and then never heard again later.

In practice, if you aren't sure whether to make a variable a float or a double, make it a double.  There are instances where you would want to use a float, but it's not going to matter if there are floats that are scattered about as single variables, even in large programs.  It will only make a difference if you say, want to declare a real valued 4 dimensional array of 100x100x100x100, or something like that.

However, I believe this algorithm takes a long time to converge to more than 6 correct decimal places (over a day, at least?)

Yeah, I think a lot of the simpler ones take a really long time to converge.  This one:

Code: [Select]

  1 #include <stdio.h>
  2 #include <math.h>
  3
  4 int main()
  5 {
  6     double numerator = 3;
  7     signed int mode = -1;
  8     double pi = 4;
  9
 10     int itteration = 0;
 11
 12     while( itteration < 100000000 )
 13     {
 14         pi += (4 / (mode * numerator));
 15
 16         numerator += 2;
 17         mode *= -1;
 18
 19         itteration++;
 20     }
 21
 22     printf("%fl\n", pi);
 23 }

Converges to 3.1415931 after 1*10^8 iterations.

[iago]

you want to use the most accurate datatype possible, which is double (without making inventing your own or implementing some other one).  I don't think double and float have the same number of bytes allocated for the mantissa, in which case the double would almost surely have more.

Two things, both of which are strictly irrelevant.

First, java.math.BigDecimal is an arbitrarily precise datatype, so if you're really interested in accuracy you're better off using that. Of course, it's way slower than a double, too.

Second, no bytes are explicitly allocated to the mantissa or to the integer ("characteristic", to be technical, though I hate that word) part, the entire 64-bits for a double or 32-bits for a float (in Java) are allocated to both halves and divided up when necessary. So if you have a huge decimal, more will be used for the mantissa, and if you have a huge integer, more will be used for the integer. You're mostly right, just the wording is a little off -- a double does have more memory allocated for storage.