Standard PI constant

After googling for a while, I found this:

Quote:

---

However, it should be noted that the math constants are actually not part of the C++ standard. A standard's conforming way to get pi is to use an expression such as const double PI(4.0 * std::atan2(1.0, 1.0));.

---

Is this true, that there is no predefined PI constant that is part of the C++ standard?

I think the M_PI macro in <cmath> is standard, but I'm not sure.

Ahhh, just what I was thinking of.. that's actually what I was googling and boardsearching for, lol! But I'd still like to hear from the gurus if this is really standard, or if it's an unofficial extension to the <cmath> header.

[self-hijack]
I like the new sig, it has a mystic aura about it :D
[/self-hijack]

My only doubt would be that M_PI may may be one the the "math constants" that was referred to in your quote. But as far as I can remember, it has been there on every compiler I have used(maybe because they are part of C's standard but not C++?). At any rate, I think the M_ macros are pretty surefire.

"Don't complain. Everything is perfect here and you have no right."

lol, that's so awesome :D

i think the floating point version of ( 22 / 7 ) might also be another way

Code:

---

float pi = 22/7 ;

---

Get an arbitrary-precision floating point number class and then just load in the first few thousand digits of pi... Who needs standards. ;)

>i think the floating point version of ( 22 / 7 ) might also be another way

22/7 is kind of like pseudo-PI. If you type that into a calculator, you'll get 3.142857, and the first few digits of PI are 3.1415927. It's close, but for many(probably most) situations, not close enough.

Code:

---

#include <stdio.h>

int main(void)
{
    float pi = 22/7;
    printf("%f",pi);
    return 0;
}

---

i got 3.000000

Code:

---

#include <stdio.h>

int main(void)
{
    float pi = 22;
    pi /= 7;
    printf("%f",pi);
    return 0;
}

---

i got 3.142857

Thats because you are doing integer arithmetic on the first version. Change it to:

Code:

---

#include <stdio.h>

int main(void)
{
    float pi = 22.f/7;
    printf("%f",pi);
    return 0;
}

---

Hunter2, it's true.

There is no M_PI constant defined in the <cmath> header according to the standard. The only macro defined in that header is HUGE_VAL.


EDIT:
What would be the advantage of using the atan2 function and a multiplication to calculate pi?
I'd just use acos to calculate pi

Code:

---

const float pi = acos(-1);

---

Although I really would prefer

Code:

---

const float pi = 3.141592...;

---

Just define it manually. Nobody except for a very limited few cases needs more than, say, the first 25-30 digits of PI anyway.

http://theory.cs.iitm.ernet.in/~arvindn/pi/

That's the first 1,000 digits after the decimal point. If you're really that desperate, just use a const float with those 1,000 digits. And prepare for muchos accuracy.

it is a pity the Pi is not a integer

>>Just define it manually. Nobody except for a very limited few cases needs more than, say, the first 25-30 digits of PI anyway.
I've actually memorized PI to about the 36'th digit or so, but where possible I prefer to not to rely on limited precision like that (whether the added precision is needed or not). And to hardcode 1000+ digits would add another 1kb to my source file, and if Joe Shmo decides to modify one digit then it's all off ;) Problem with 22/7 is that while it's possibly very precise, it's certainly not accurate.

Sang-Drax: After googling on M_PI (much more successful than PI C++ standard cmath :D), I came to the same conclusion (everywhere said it was nonstandard).
>>What would be the advantage of using the atan2 function and a multiplication to calculate pi?
I'm not sure if there is one. Possibly the algorithm for finding acos is less accurate/precise than for atan? Anyway, the *4 multiplication would mean a potential loss of (I think) a digit or two of accuracy. I also noticed that in Visual Basic there's no acos/asin functions, you must calculate them by using atn (atan) and manipulating the result. Does anyone know more about this?

355 / 113 is a better approximation.

Interesting. I just realized, double isn't as precise as I thought :D It only stores 16 decimal places of PI anyways, while I know 30+.

But strangely, the last decimal place is rounded down incorrectly... it stores
3.1415926535897931 instead of
3.1415926535897932, where the real number is
3.14159265358979323.

Regardless of whether it is rounded or truncated, shouldn't the last digit be 2 instead of 1? (acos(-1.) gives the same result)

Well... It is double precision in that it is twice the storage space (at least on machines that I've worked on; I know of no other requirement in the standard other than sizeof(float) <= sizeof(double)), but remember that the number is stored in binary format. Do a google search on the IEEE standard for storing floating point numbers, and you will likely get more in-depth answers to your questions.

Wow, just read an article about it. But I still don't have a solid answer for my question - I sort of get the impression that it's because of the fact that there may be no true binary representation for the correctly rounded (or base 10 truncated) value. Am I correct?

>> Am I correct?
Most likely.

For those who don't already have a copy:
What Every Computer Scientist Should Know About Floating-Point Arithmetic
and
comp.lang.c Frequently Asked Questions (Section 14)

gg

Thanks everyone :)

Just make PI 3.14 and run with it :)

No, in all seriousness this is a very interesting thread and will be of great use to me (and others) in the future.