OJ Board

Does C++ have its own math library or do I have to use ANSI C's math.h library for math operations?

C++ just wraps old math.h in cmath (as usual). You can see in http://www.boost.org that a lot of additional functionality is proposed, however it has yet to come to standard libs to be used in contest environment (of course, for 'normal' projects you can find a lot more than math.h)

Actually the judge is using his own version of math library.

I've just send my code for 149 - Forests problem and got compile error:

`M_PI' was not declared in this scope
`M_3PI_4' was not declared in this scope

M_PI is a definition from math.h header file present in two different g++ 2.95 compilers that I have and in g++ 3.2 as well. I am wondering what else was removed from math.h.

For pi, you can use acos(-1.0).

I defined MY_PI_2 as 1.57079632679489661923, but I shouldn't have to. I would love to know what was the purpose of removing PI definition.

M_PI hasn't been removed, if you look in math.h you'll see that it's definition is encapsuled in a [c]#if defined __USE_BSD || defined __USE_XOPEN[/c], meangin that it is only avalaible in sources using BSD or XOPEN extensions (wich is the default for gcc). It also implies that it is not part of the ANSI C specification. When you compile for ACM, you must use the [c] -ansi [/c] flag to ensure that your code is 100% Ansi compatible. This reduce the set of functions or constant you can use, but allows everybody to code on the same basis : no one will be more advantaged than another because the judge uses the same version of the compiler as him : everybody will have to use the same set of functions. That's more fair (and more fun), isn't it ?

Julien Cornebise wrote:For pi, you can use acos(-1.0).

What about

[c]

#define PI 2*acos(0)

[/c]

?

That's the worst solution. For every reference to PI, acos(0) is evaluated again and again, which takes a lot of time - define macro simply replaces PI by 2*acos(0).

If you want to do define pi this way, the only way is the following:
[cpp]const SUITABLE_FLOAT_TYPE PI 2*acos(0)[/cpp]
Here, acos(0) is evaluated only once and then stored in variable PI.

That's what was of course implied in my answer.
Eitherway, it doesn't hurt to precise it explicitely.

I know - my remark was adressed to Moni. He, not you, used acos(0). BTW - I think it should be here acos(0.0), otherwise the code may not compile (I don't know, I haven't checked, but that's a common problem with funtions from math library).

Krzysztof Duleba wrote:That's the worst solution. For every reference to PI, acos(0) is evaluated again and again, which takes a lot of time - define macro simply replaces PI by 2*acos(0).

If you want to do define pi this way, the only way is the following:
[cpp]const SUITABLE_FLOAT_TYPE PI 2*acos(0)[/cpp]
Here, acos(0) is evaluated only once and then stored in variable PI.

Oh! Yeah!

I once used it in C...........but for C++

[cpp]

#include<cmath>

const double PI = 2.0 * acos(0.0);

[/cpp]

Is always I use!

Thanks for reminding!

Krzysztof Duleba wrote:I know - my remark was adressed to Moni. He, not you, used acos(0). BTW - I think it should be here acos(0.0), otherwise the code may not compile (I don't know, I haven't checked, but that's a common problem with funtions from math library).

Hi
Under gcc, it does compile, it implicitely converts from int to double. But it is compiler dependant, of course.

We're talking about C++, not C, so you should use g++ instead of gcc. And g++ gave me this output:

t.cpp:7: call of overloaded `acos(int)' is ambiguous
/usr/include/math.h:51: candidates are: double acos(double)
/usr/include/c++/3.2/cmath:112: long double std::acos(long double)
/usr/include/c++/3.2/cmath:99: float std::acos(float)

That's because almost all the funcions are written in two (for doubles and long doubles) or even three (floats, doubles and long doubles) types of arguments and int can be converted to all of them.

okay, that's thanks to C++ and its allowance for method overloading (same name, different parameters types) and its resolution method. This problem doesn't arise in C, and given that I'm new to C++ (but long time C programmer) I forgot that little detail

Juilen, you said before that I should use -ansi option. So another funny thing: my solution of problem 155 was refused because

"`abs' undeclared"

On my PC the code with g++-2 -ansi 155.cpp -o 155.exe compiles just fine. So I ask once again: what else is different than it should be