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]

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

[Ben Rudiak-Gould]

Post by giaro
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]

Post by giaro
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

[Joel Yliluoma]

Post by Clemens Buchacher

Post by giaro
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 :)

[Johannes Bauer]

Post by giaro
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

[osmium]

Post by Johannes Bauer

Post by giaro
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]

Post by osmium
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

[osmium]

Post by Johannes Bauer

Post by osmium
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]

Post by osmium
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.

[James Kanze]

Post by Johannes Bauer

Post by osmium
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:***@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Alf P. Steinbach]

Post by James Kanze

Post by Johannes Bauer

Post by osmium
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.

Post by James Kanze
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

[Pete Becker]

Post by Alf P. Steinbach

Post by James Kanze

Post by Johannes Bauer

Post by osmium
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.

Post by Alf P. Steinbach

Post by James Kanze
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.

[James Kanze]

[...]

Post by Pete Becker

Post by Alf P. Steinbach

Post by James Kanze
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:***@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Greg Herlihy]

Post by osmium

Post by Johannes Bauer

Post by giaro
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/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

[James Fang]

Post by Greg Herlihy

Post by osmium

Post by Johannes Bauer

Post by giaro
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.
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.

[James Kanze]

On Dec 3, 6:35 am, Greg Herlihy <***@mac.com> wrote:

[...]

Post by Greg Herlihy
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:***@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Erik Wikström]

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