sometimes not #include <XX>also work

[ylxin1993]

look, I didn't #include <ios>, and this program also works, and produces answer.

#include <iostream>
int main() {
    double pi = 3.141592653589792;
    std::cout << std::scientific << pi << std::endl;
    return 0;
}

3.141593e+000

I use eclipse+MinGW;

why??? I found this too much.

ps. I think it's cumbersome to writed things with std::, if we want to set the output format, there's too many std:: prefix to use, why someone prefer ust std:: each time needed to just use using namespace std; ?

[Moschops]

In your system, whoever wrote iostream probably put #include <ios> in there.

why someone prefer ust std:: each time needed to just use using namespace std; ?

http://stackoverflow.com/questions/1452721/why-is-using-namespace-std-considered-a-bad-practice-in-c

[TheIdeasMan]

I think iostream includes ios.h. There is a class hierachy for ios stuff.

As far as std:: goes there a couple of things you can do:

#include <iostream>

using std::cin;
using std::cout;
using std::endl;
//same for other std things

int main() {
    double pi = 3.141592653589792;
    cout << std::scientific << pi << endl;
    return 0;
}

I tend to do that for things that are used a lot, then put std:: for things that aren't (like scientific in this example)

HTH

Edit: If you include cmath you can use M_PI directly without having to define your own constant. There are other math constants also. Look at the math.h file

[o1vk4iN6]

Thought M_PI was removed from the standard library ?

[Peter87]

#include <ios> is listed in the Header <iostream> synopsis in the standard §27.4.1. Does that mean <ios> has to be included by <iostream> or what? I can't see it saying that explicitly.

TheIdeasMan wrote:

If you include cmath you can use M_PI directly without having to define your own constant.

M_PI is not standard, and has never been.

[TheIdeasMan]

Peter87 wrote:

M_PI is not standard, and has never been.

Well I am surprised by that. It may not be part of the standard library, but on all the systems I have ever used since 1987, it is in math.h which is included in cmath. Is it that I am lucky that this is the case for gcc 4.7 ?

It seems strange to me that math constants are not part of standard system, they are used frequently by coders wanting to do math type applications - why should the coder have to define their own version?

I was reading that the boost library has math constants built in. Is it true that some things are not in the STL because they are so readily available in boost?

[o1vk4iN6]

Well how hard is it to declare your own constants ? Also the FPU has an instruction to load PI into the top register but I haven't seen anything take advantage of that yet.

[Peter87]

TheIdeasMan wrote:

It seems strange to me that math constants are not part of standard system, they are used frequently by coders wanting to do math type applications - why should the coder have to define their own version?

I don't know why. Maybe they think it's not needed because it could easily be calculated as std::acos(-1). Defining a global constant/macro is more of the C way of doing it. If C++ adds it to the standard I guess it would have been something similar to std::numeric_limits but for math constants, to be able to handle all the floating point types correctly, which would be more verbose than just using M_PI.

TheIdeasMan wrote:

I was reading that the boost library has math constants built in. Is it true that some things are not in the STL because they are so readily available in boost?

I don't think so. A lot of things in C++11 was taken from boost.

ylxin1993 wrote:

double pi = 3.141592653589792;

The last digit should be 3, not 2.

[TheIdeasMan]

Well how hard is it to declare your own constants ?

Not hard, but why should I? There is potential for error, if one types it in wrong. Something I would personally be very careful about - if I had to do it.

An suspecting coder might define the constant with only 6 dp, then wonder why they have errors in some situations. You could get the value from your calculator - but what if only does 8dp?

Much easier to use M_PI or M_E say and not worry about it.

I do mathematical apps, all the time - I would find it a real pain to define my own constants all the time - that is part of what math headers are for IMO.

This is about on par with when I learnt that main does not have explicitly return an int.

[TheIdeasMan]

Thanks Peter for your always educational posts.

I did my last post before reading yours.

I guess I do still think with a "C" mentality, because that is what I learnt first.

If C++ adds it to the standard I guess it would have been something similar so std::numeric_limits but for math constants, to be able to handle all the floating point types correctly, which would be more verbose than just using M_PI.

Yes, I think boost does something similar.

BTW, I have a really geeky T-shirt that has pi to 8,000 dp !! I haven't been game to wear it anywhere though :)

For those who want to make their own constants - from math.h

/* Some useful constants.  */
#if defined __USE_BSD || defined __USE_XOPEN
# define M_E		2.7182818284590452354	/* e */
# define M_LOG2E	1.4426950408889634074	/* log_2 e */
# define M_LOG10E	0.43429448190325182765	/* log_10 e */
# define M_LN2		0.69314718055994530942	/* log_e 2 */
# define M_LN10		2.30258509299404568402	/* log_e 10 */
# define M_PI		3.14159265358979323846	/* pi */
# define M_PI_2		1.57079632679489661923	/* pi/2 */
# define M_PI_4		0.78539816339744830962	/* pi/4 */
# define M_1_PI		0.31830988618379067154	/* 1/pi */
# define M_2_PI		0.63661977236758134308	/* 2/pi */
# define M_2_SQRTPI	1.12837916709551257390	/* 2/sqrt(pi) */
# define M_SQRT2	1.41421356237309504880	/* sqrt(2) */
# define M_SQRT1_2	0.70710678118654752440	/* 1/sqrt(2) */
#endif 

[o1vk4iN6]

There is still potential for error, your just assuming that whoever wrote it in the standard didn't make an error. Not sure what the specifications were of M_PI when it was still defined but who's to say it met your needs ? What if I am on a computer that has a 128 bit floating point precision number. M_PI is now invalid for my computer and by your assumption I would never solve the problem cause I assume M_PI is what I need and would never have a second thought.


Why would you go to a calculator to get PI ? There's your problem.

http://www.wolframalpha.com/input/?i=PI

Just keep hitting more digits.

[ne555]

http://www.gnu.org/software/libc/manual/html_node/Mathematical-Constants.html
These constants come from the Unix98 standard and were also available in 4.4BSD; therefore they are only defined if _BSD_SOURCE or _XOPEN_SOURCE=500, or a more general feature select macro, is defined. The default set of features includes these constants.

What if I am on a computer that has a 128 bit floating point precision number.

All values are of type double. As an extension, the GNU C Library also defines these constants with type long double. The long double macros have a lowercase ‘l’ appended to their names: M_El, M_PIl, and so forth. These are only available if _GNU_SOURCE is defined.

[TheIdeasMan]

Why would you go to a calculator to get PI ? There's your problem.

That is not what I would do - I meant a newbie might do that.

The values in math.h (shown above) are to 20 dp and would be sufficient for use with doubles, and I am guessing that was the intention back in the days of ANSI C. Also I would have thought that the double type would be sufficient for most applications IMO. Problems with precision are often avoided by changing the units - astrophysicists use light years instead of metres as an example. That is not say that there are applications that do need extended precision.

Sure if you are using a 128 bit FP then you would need something else. I was not proposing it was a solution for everything, although it is my fault for making it sound like that. What I really meant was there should be some sort of built in value.

This brings me to the boost library again. I was reading that their value of pi is good to 100dp!! Hopefully that is good enough for everyone.

Now a case in point. Peter87 has pointed out that the OP had the last digit incorrect. If M_PI (or some other even more precise value) was available to the OP - then that would not have happened.

Any way thanks for your counterpoint - some debate is good, one never knows what one might learn.

Cheers :)

[Cubbi]

To give a bit more info on the availability of M_PI: it likely started in BSD (as the GNU doc above says) and after defeating its rival PI (due to less likely naming collisions) it became part of the Single Unix Specification, which later merged with POSIX where M_PI became a part of the XSI extension to the POSIX standard.

SUSv2 1997:
http://pubs.opengroup.org/onlinepubs/7908799/xsh/math.h.html
POSIX 2004:
http://pubs.opengroup.org/onlinepubs/000095399/basedefs/math.h.html
POSIX 2008:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/math.h.html

Microsoft also supports it, although it requires a special #define:
MSDN: http://msdn.microsoft.com/en-us/library/4hwaceh6(v=vs.110).aspx

It has never been part of C or C++, but boost introduced it in its math.constants library in 2006, which now defines both function templates such as boost::math::constants::pi<double>(); and constants such as boost::math::double_constants::pi

http://www.boost.org/doc/libs/release/libs/math/doc/sf_and_dist/html/math_toolkit/constants.html

[TheIdeasMan]

Awesome - thanks Cubbi :+D

There is a lot of great stuff in boost - I should make more use of it in my projects.