extracting PI value from cmath

[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

[Victor Bazarov]

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 e-mail
I do not respond to top-posted replies, please don't ask

[Ben Rudiak-Gould]

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 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

[Clemens Buchacher]

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

[Johannes Bauer]

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>

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2007-12-01 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

[osmium]

"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.

[Johannes Bauer]

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
Avogadro-number 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>

[osmium]

"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
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.

[Pete Becker]

On 2007-12-01 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 non-conforming.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

[James Kanze]

On Dec 1, 7:41 pm, Johannes Bauer <[e-mail]:

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 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.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Pete Becker]

On 2007-12-02 09:05:42 -0500, "Alf P. Steinbach" <al***@start.nosaid:

* James Kanze:

>On Dec 1, 7:41 pm, Johannes Bauer <[e-mail]:

>>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 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.

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)

[Greg Herlihy]

On Dec 1, 10:32 am, "osmium" <[e-mail]:

"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

[James Fang]

On Dec 3, 1:35 pm, Greg Herlihy <[e-mail]:

On Dec 1, 10:32 am, "osmium" <[e-mail]:

"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.

[James Kanze]

On Dec 3, 6:35 am, Greg Herlihy <[e-mail]:

[...]

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

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Joel Yliluoma]

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/

[James Kanze]

On Dec 2, 5:53 pm, Pete Becker <[e-mail]:

On 2007-12-02 09:05:42 -0500, "Alf P. Steinbach" <[e-mail]:

* 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.-Cyr-l'École, France, [phone]