extracting PI value from cmath

G

giaro

Hi,
I'm doing some maths and I've just found that the standard library
does not provide a standard PI value. In older post I see everyone says
you must define it by yourself, but as some of the standard functions
are in fact supposed to return that value, I feel there must be a better
way. For example, here's what a google search returned:

float PI = std::atan(1.0f) * 4.0f;

Anything more accurate?

Thanks
 
V

Victor Bazarov

giaro said:
Hi,
I'm doing some maths and I've just found that the standard library
does not provide a standard PI value. In older post I see everyone
says you must define it by yourself, but as some of the standard
functions are in fact supposed to return that value, I feel there
must be a better way. For example, here's what a google search
returned:
float PI = std::atan(1.0f) * 4.0f;

Anything more accurate?

This should be accurate enough.

You can define one yourself (3.1415926f for float should be enough)
and then compare this to the result you get using atan.

V
 
B

Ben Rudiak-Gould

giaro said:
float PI = std::atan(1.0f) * 4.0f;

Anything more accurate?

std::atan(1.0f) should return pi/4 to within 0.5 ulp (though I don't think
the standard guarantees this). Multiplying by 4.0 will still give an answer
accurate to 0.5 ulp if the floating-point base is 2 (or 4). So I would think
that more accuracy is impossible. Perhaps pi = std::atan2(0.0f,-1.0f) would
be slightly safer since it doesn't depend on the base.

-- Ben
 
C

Clemens Buchacher

giaro said:
float PI = std::atan(1.0f) * 4.0f;
Anything more accurate?

double pi = 4 * std::atan(1);

Any inaccuracy here is likely due to the limited precision of float or double
rather than this method of computation. I checked by getting 22 digits or so
from http://www.piday.org/million.php and when assigned to double the result
matches exactly to pi as computed above. (gcc 4.2.1, glibc 2.6.1)

Clemens
 
J

Johannes Bauer

giaro said:
I'm doing some maths and I've just found that the standard library
does not provide a standard PI value.

Isn't "M_PI" a defined symbol? Maybe I mix it up with something else?

Greetings,
Johannes
 
E

Erik Wikström

Hi,
I'm doing some maths and I've just found that the standard library
does not provide a standard PI value. In older post I see everyone says
you must define it by yourself, but as some of the standard functions
are in fact supposed to return that value, I feel there must be a better
way. For example, here's what a google search returned:

float PI = std::atan(1.0f) * 4.0f;

Anything more accurate?

If your implementation is POSIX compliant (most are) you should have
M_PI defined which should be as accurate as double permits.
 
O

osmium

Johannes Bauer said:
Isn't "M_PI" a defined symbol? Maybe I mix it up with something else?

M_PI is an add on offered by many compilers, including Borland. Thus it is
not standard. ISTM that the authors of the standard could have found a
better way/wording to handle extensions, thus avoiding this recurring
misunderstanding.
 
J

Johannes Bauer

osmium said:
M_PI is an add on offered by many compilers, including Borland. Thus it is
not standard. ISTM that the authors of the standard could have found a
better way/wording to handle extensions, thus avoiding this recurring
misunderstanding.

That's a shame - is this resolved in C++0x? Pi is a constant which is
*very* common, one could also include Planck's constant and the
Avogadro-number IMHO (as it doesn't make any difference if not used).

Greetings,
Johannes
 
O

osmium

Johannes Bauer said:
That's a shame - is this resolved in C++0x? Pi is a constant which is
*very* common, one could also include Planck's constant and the
Avogadro-number IMHO (as it doesn't make any difference if not used).

I guess there is some clever sarcasm in there but I am unable to disentangle
it to find your point so I can't respond to it.

*My* point was that there is no reasonable way to determine whether an
identifier is valid and usable. And the only way I know of to see if a
*program's* source code is valid is to compile it on some sort of
certified - sort of - compiler. Perhaps Comeau.

The compiler's vendors have done cherry picking on the list of valid id's
and appropriated some of them for their own use, including M_PI. They are
then permitted to legally add
their declaration to a standard library, cmath. If I accidentally use M_PI
as an identifier I may see some very mysterious error messages. OTOH if I
release what I think is a standard bit of source code I
have to go through a private hell to confirm that it really can, in fact,
be compiled at will by someone else.

Whether constants should be included in a programming language or not is an
entirely separate issue - my current argument is the method permitted, not
the desired end result.
 
P

Pete Becker

The compiler's vendors have done cherry picking on the list of valid id's
and appropriated some of them for their own use, including M_PI. They are
then permitted to legally add
their declaration to a standard library, cmath.

Legally, yes: there's no law prohibiting it. But adding identifiers
that aren't specified by the language definition (other than names
reserved to the implementor, which M_PI is not) makes the
implementation non-conforming.
 
J

James Kanze

osmium schrieb:
That's a shame - is this resolved in C++0x? Pi is a constant
which is *very* common, one could also include Planck's
constant and the Avogadro-number IMHO (as it doesn't make any
difference if not used).

Not that I know of. It's an interesting point. Having
something along the lines of numeric_limits, but for a number of
notable constants (pi and e are, of course, essential, but there
are doubtlessly a number of others which would make sense)
actually sounds like a good idea, but I'm not aware of anyone
ever having made such a proposal. (One immediate question:
should only dimensionless constants be considered? Or should
one also support things like the gravitational constant, and if
so, only in SI, are also in other common systems.)
 
A

Alf P. Steinbach

* James Kanze:
Not that I know of. It's an interesting point. Having
something along the lines of numeric_limits, but for a number of
notable constants (pi and e are, of course, essential, but there
are doubtlessly a number of others which would make sense)
actually sounds like a good idea, but I'm not aware of anyone
ever having made such a proposal.

It's been discussed in clc++, clc++m and I think also csc++ several
times. I've asked about it a number of times.

(One immediate question:
should only dimensionless constants be considered? Or should
one also support things like the gravitational constant, and if
so, only in SI, are also in other common systems.)

And that's how such practical ideas end. Instead of thinking
standardization of existing practice (should be easy, M_PI and possibly
M_E, whatever), the measure must also save the world.

Cheers,

- Alf
 
P

Pete Becker

* James Kanze:

It's been discussed in clc++, clc++m and I think also csc++ several
times. I've asked about it a number of times.

As always: if it matters to you, write a proposal. It's far too late
for C++0x, though.
And that's how such practical ideas end. Instead of thinking
standardization of existing practice (should be easy, M_PI and possibly
M_E, whatever), the measure must also save the world.

Speculating about natural extensions is a critical part of design.
 
G

Greg Herlihy

M_PI is an add on offered by many compilers, including Borland. Thus it is
not standard. ISTM that the authors of the standard could have found a
better way/wording to handle extensions, thus avoiding this recurring
misunderstanding.

M_PI, M_SQRT2, M_LN2 and the other, related macros that are found in
math.h - are defined by the POSIX Standard - and have been for years.
See:

http://www.opengroup.org/onlinepubs/009695399/basedefs/math.h.html

So there is certainly no reason not to use M_PI - especially since the
POSIX Standard guarantees that M_PI is the most accurate value for pi
that a double can represent.

Greg
 
J

James Fang

M_PI, M_SQRT2, M_LN2 and the other, related macros that are found in
math.h - are defined by the POSIX Standard - and have been for years.
See:

http://www.opengroup.org/onlinepubs/009695399/basedefs/math.h.html

So there is certainly no reason not to use M_PI - especially since the
POSIX Standard guarantees that M_PI is the most accurate value for pi
that a double can represent.

Greg

Are they in ansi C stardard? As far as I am concerned,the posix don't
care about the math related things.
 
J

James Kanze

[...]
So there is certainly no reason not to use M_PI - especially since the
POSIX Standard guarantees that M_PI is the most accurate value for pi
that a double can represent.

Which means that it's less than what is wanted if I'm using long
double. IIRC, Intel processors have a built-in pi constant.
Using this, instead of any external constant, should result in
greater precision. I'm not sure how Posix defined it, but some
sort of compiler magic triggering use of this built in constant
should be allowed, i.e.:
#define M_PI __builtin_pi
 
J

James Kanze

[...]
Speculating about natural extensions is a critical part of design.

In this case, "speculating" is very much the correct word. I
wasn't making a proposal, just speculating as to what a C++
proposal might look like. Fundamentally, I more or less agree
with Alf; just make the Posix extension part of standard C (and
because it's in <math.h>, it's really a question for C, and not
C++), for starters. About the only point I'd insist on is that
the macros could expand to things like __builtin_pi, so that the
compiler could actually use the value built into the math
processor, if it exists.

Of course, since I don't do much numeric programming anyway,
it's no big thing for me, and if the numericists don't care (and
apparently they don't since they've never presented a proposal),
that's their problem, not mine.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top