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 16 37569
giaro wrote:
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

Please remove capital 'A's when replying by email
I do not respond to topposted replies, please don't ask
giaro wrote:
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 floatingpoint 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
giaro <no****@here.inwrote:
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
giaro schrieb:
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

"Viele der Theorien der Mathematiker sind falsch und klar
GotteslÃ¤sterlich. Ich vermute, dass diese falschen Theorien genau
deshalb so geliebt werden."  Prophet und VisionÃ¤r Hans Joss aka
HJP in de.sci.mathematik <47**********************@news.sunrise.ch>
On 20071201 12:51, giaro wrote:
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.

Erik WikstrÃ¶m
"Johannes Bauer" writes:
giaro schrieb:
> 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?
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.
osmium schrieb:
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
Avogadronumber IMHO (as it doesn't make any difference if not used).
Greetings,
Johannes

"Viele der Theorien der Mathematiker sind falsch und klar
GotteslÃ¤sterlich. Ich vermute, dass diese falschen Theorien genau
deshalb so geliebt werden."  Prophet und VisionÃ¤r Hans Joss aka
HJP in de.sci.mathematik <47**********************@news.sunrise.ch>
"Johannes Bauer" writes:
osmium schrieb:
>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
Avogadronumber 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.
On 20071201 15:57:02 0500, "osmium" <r1********@comcast.netsaid:
>
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 nonconforming.

Pete
Roundhouse Consulting, Ltd. ( www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
( www.petebecker.com/tr1book)
On Dec 1, 7:41 pm, Johannes Bauer <dfnsonfsdu...@gmx.dewrote:
osmium schrieb:
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 Avogadronumber 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.)

James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.Cyrl'École, France, +33 (0)1 30 23 00 34
On 20071202 09:05:42 0500, "Alf P. Steinbach" <al***@start.nosaid:
* James Kanze:
>On Dec 1, 7:41 pm, Johannes Bauer <dfnsonfsdu...@gmx.dewrote:
>>osmium schrieb:
>>>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 Avogadronumber 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.
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.
>
> (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.
Speculating about natural extensions is a critical part of design.

Pete
Roundhouse Consulting, Ltd. ( www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
( www.petebecker.com/tr1book)
On Dec 1, 10:32 am, "osmium" <r124c4u...@comcast.netwrote:
"Johannes Bauer" writes:
giaro schrieb:
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?
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/...fs/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
On Dec 3, 1:35 pm, Greg Herlihy <gre...@mac.comwrote:
On Dec 1, 10:32 am, "osmium" <r124c4u...@comcast.netwrote:
"Johannes Bauer" writes:
giaro schrieb:
> 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?
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/...fs/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.
On Dec 3, 6:35 am, Greg Herlihy <gre...@mac.comwrote:
[...]
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 builtin 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

James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.Cyrl'École, France, +33 (0)1 30 23 00 34
On Sat, 1 Dec 2007 16:48:55 +0000 (UTC), Clemens Buchacher wrote:
giaro <no****@here.inwrote:
>float PI = std::atan(1.0f) * 4.0f;
>Anything more accurate?
double pi = 4 * std::atan(1);
Or double pi = std::atan2(0,1);
Because for constants, 0, 1 and 1 feel less magical than 4 does :)

Joel Yliluoma  http://iki.fi/bisqwit/
On Dec 2, 5:53 pm, Pete Becker <p...@versatilecoding.comwrote:
On 20071202 09:05:42 0500, "Alf P. Steinbach" <al...@start.nosaid:
* James Kanze:
[...]
(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.
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.

James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.Cyrl'École, France, +33 (0)1 30 23 00 34 This discussion thread is closed Replies have been disabled for this discussion. Similar topics
4 posts
views
Thread by Edwin Young 
last post: by

2 posts
views
Thread by Robert Carlson 
last post: by

1 post
views
Thread by Cognizance 
last post: by

reply
views
Thread by rowyerboat 
last post: by

4 posts
views
Thread by nephish 
last post: by

13 posts
views
Thread by Randy 
last post: by

1 post
views
Thread by Mark Dickinson 
last post: by
 
3 posts
views
Thread by KSor 
last post: by
          