2

Hi i have built an algorithm to calculate pi but i use long float for it so i just get 3.14159 as a result, i need more precision. How? here is the code:

    #include <iostream>
#include <math.h>
using namespace std;

int main ()
{
  long double a, l, p, pi, r;
  long long int n, m;
  r = 100000;
  a = r * sqrt (3) / 2 ;
  n = 100000;
  m = 6;
  while (n > m)
  {
    a = sqrt (r / 2 * (r + a));
  m = m * 2 ;
  }
  l = sqrt (4 * (pow (r, 2) - pow (a, 2)));
  p = m * l;
  pi = p / (2 * r) ;
  cout << pi << endl;
  cout << "number of corners used: " << m << endl;
  return 0;
}

By the way there is a 24 core (12 dual core nodes) supercomputer at my high school, just in case

  • If your algorithm for computing pi needs a 24-core supercomputer, you're doing it wrong. Additional cores wouldn't even help here since you're not using threads. – tadman Dec 18 '14 at 19:08
  • Well, one way to get better precision (and in constant time) would be: `cout << M_PI;`. – i_am_jorf Dec 18 '14 at 19:10
  • If your ambition is to calculate decimals of pi you may consider using some kind of integer array to store the decimals. This will of course require some modification to your algorithm. – warsac Dec 18 '14 at 19:17

3 Answers3

4

If you really want more precision (not just display more decimal places), you could consider using the GMP (Gnu Multi-precision) Library. You can specify the number of bytes to use for your doubles (8 bytes, 16 bytes, 32 bytes, 64 bytes, 128 bytes, ... ). The library is usually used for cryto algorithms (that need really large integers).

https://gmplib.org/

You'll probably want to look at this similar thread: C++ calculating more precise than double or long double

Community
  • 1
  • 1
TravisJ
  • 1,592
  • 1
  • 21
  • 37
0

There's more precision in that number than you're displaying. You just have to ask for it:

cout << std::setprecision(40) << pi << endl;

That gives me 3.141592653543740176758092275122180581093 when run on Codepad.

As double should have way more than enough precision for basic calculations. If you need to compute millions of places, there isn't a standard floating point representation big enough to handle that.

tadman
  • 208,517
  • 23
  • 234
  • 262
  • trying to shoot the computer out of it's limits – Sakhs Modioths Dec 18 '14 at 19:14
  • It's not correct to say that "long double is not supported". Rather, the Standard doesn't require it to have any more precision than just `double`. But it absolutely is specified as part of the language, and required to support all the same operations as the other two floating-point types. BTW, [there is no "ANSI C++"](http://stackoverflow.com/q/5863051/103167) only ISO C++ – Ben Voigt Dec 18 '14 at 19:14
  • error: 'setprecision' is not a member of 'std'| what did i did wrong using code blocks – Sakhs Modioths Dec 18 '14 at 19:16
  • `long double is not supported in ANSI C++`. Huh?! It is absolutely supported, it is different from double for example on MinGW-w64 and it does provide one with better precision – Severin Pappadeux Dec 18 '14 at 19:26
  • My mistake. The compiler warning was: "Line 8: error: ISO C++ does not support 'long long'". – tadman Dec 18 '14 at 19:31
  • 1
    @SakhsModioths You need to include a library: #include – Lanet Nov 03 '19 at 12:21
0
cout.precision(400);
  cout << pi << endl;
  • 1
    Be aware that this will print 400 digits, but most of them will be garbage bits (because an 8 Byte double won't contain that much precision). – TravisJ Dec 18 '14 at 19:33
  • Absolute best case scenario you get 323 "good" digits when using a 8 byte double. But, in practice because of numerical issues you'll have far fewer accurate digits. – TravisJ Dec 18 '14 at 19:40
  • 400 is an example FPU of most cpus is 64bits those day (some opterons with 256bit) – Sakhs Modioths Dec 18 '14 at 23:04
  • Any representable floating point number (with 8 bytes) will look like M*2^e where e>= -1024 and M is an integer. The smallest number you can therefore represent (positive number) is 1/2^1024 which has 323 decimal digits. – TravisJ Dec 19 '14 at 14:28