I am compiling with an old software TurboC++ 4.5(1995) and I am having some errors. Can anyone help?
#include<iostream.h>
#include<math.h>
void cal_root(int,int,int,float&,float&);
void main()
{
float root1=0,root2=0;
int a,b,c;
cout<<"Enter the three co-efficients of quadratic equation with spaces.\n";
cin>>a>>b>>c;
cal_root(a,b,c,root1,root2);
cout<<"The roots for given Quadratic Equation are "<<root1<<" & "<<root2<<".";
}
void cal_root(int a,int b,int c,float& root1,float& root2)
{
root1=-b+(sqrt((b*b)-4ac))/(2a); //error here
root2=-b-(sqrt((b*b)-4ac))/(2a); //error here
}
I'm getting the following error:
Function call missing ) in function cal_root(int, int, int, float&, float &)
at lines 16 and 17
You can't do multiplication like this:
4ac
2a
You have to spell it out:
4 * a * c
2 * a
But make sure you are liberal with your parenthesis, because, for example, 2 * a in that expression will first divide by 2, then multiply by a. When in fact, you want to divide by 2 and divide by a.
In fact, your -b is also badly placed, due to order of operations. The expression should look like this:
(-b + sqrt((b*b) - (4*a*c)))
/ (2*a)
You're not in a math class, you have to write out multiplications explicitly:
4ac -> 4*a*c
2a -> 2*a
You cannot leave operators as you would in algebra. 4ac and 2a should be 4*a*c and 2*a.
Also, get a better compiler / IDE. Turbo C++ was the worst piece of crap when I started programming about 10 years ago. It's still that bad. Use Netbeans for example.
The simple fact that it allows for void main() proves my point. Main should never be declared void.
You can't multiply variables by constants via 2x and the like, as it gets treated as a literal, 2, with a suffix of x, or whatever your variable happens to be, suffixes changing the representation of the variable (e.g. LL would treat it as a long long).
Instead, use operator*:
4 * a * c
2 * a
You can't write 4ac or 2a - this is not maths.
Change
4ac = 4*a*c
2a = 2*a
Also void main is wrong.
First of all
void cal_root(int a,int b,int c,float& root1,float& root2)
{
root1=-b+(sqrt((b*b)-4ac))/(2a); //error here
root2=-b-(sqrt((b*b)-4ac))/(2a); //error here
}
this should be written as
void cal_root(int a,int b,int c,float& root1,float& root2)
{
root1=-b+(sqrt((b*b)-(4*a*c)))/(2*a); //correction
root2=-b-(sqrt((b*b)-(4*a*c)))/(2*a); //correction
}
secondly avoid using void in main...(just a suggestion)
Related
Consider the following piece of code:
#include <iostream>
#include <cmath>
int main() {
int i = 23;
int j = 1;
int base = 10;
int k = 2;
i += j * pow(base, k);
std::cout << i << std::endl;
}
It outputs "122" instead of "123". Is it a bug in g++ 4.7.2 (MinGW, Windows XP)?
std::pow() works with floating point numbers, which do not have infinite precision, and probably the implementation of the Standard Library you are using implements pow() in a (poor) way that makes this lack of infinite precision become relevant.
However, you could easily define your own version that works with integers. In C++11, you can even make it constexpr (so that the result could be computed at compile-time when possible):
constexpr int int_pow(int b, int e)
{
return (e == 0) ? 1 : b * int_pow(b, e - 1);
}
Here is a live example.
Tail-recursive form (credits to Dan Nissenbaum):
constexpr int int_pow(int b, int e, int res = 1)
{
return (e == 0) ? res : int_pow(b, e - 1, b * res);
}
All the other answers so far miss or dance around the one and only problem in the question:
The pow in your C++ implementation is poor quality. It returns an inaccurate answer when there is no need to.
Get a better C++ implementation, or at least replace the math functions in it. The one pointed to by Pascal Cuoq is good.
Not with mine at least:
$ g++ --version | head -1
g++ (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2)
$ ./a.out
123
IDEone is also running version 4.7.2 and gives 123.
Signatures of pow() from http://www.cplusplus.com/reference/cmath/pow/
double pow ( double base, double exponent );
long double pow ( long double base, long double exponent );
float pow ( float base, float exponent );
double pow ( double base, int exponent );
long double pow ( long double base, int exponent );
You should set double base = 10.0; and double i = 23.0.
If you simply write
#include <iostream>
#include <cmath>
int main() {
int i = 23;
int j = 1;
int base = 10;
int k = 2;
i += j * pow(base, k);
std::cout << i << std::endl;
}
what do you think is pow supposed to refer to? The C++ standard does not even guarantee that after including cmath you'll have a pow function at global scope.
Keep in mind that all the overloads are at least in the std namespace. There is are pow functions that take an integer exponent and there are pow functions that take floating point exponents. It is quite possible that your C++ implementation only declares the C pow function at global scope. This function takes a floating point exponent. The thing is that this function is likely to have a couple of approximation and rounding errors. For example, one possible way of implementing that function is:
double pow(double base, double power)
{
return exp(log(base)*power);
}
It's quite possible that pow(10.0,2.0) yields something like 99.99999999992543453265 due to rounding and approximation errors. Combined with the fact that floating point to integer conversion yields the number before the decimal point this explains your result of 122 because 99+3=122.
Try using an overload of pow which takes an integer exponent and/or do some proper rounding from float to int. The overload taking an integer exponent might give you the exact result for 10 to the 2nd power.
Edit:
As you pointed out, trying to use the std::pow(double,int) overload also seems to yield a value slightly less 100. I took the time to check the ISO standards and the libstdc++ implementation to see that starting with C++11 the overloads taking integer exponents have been dropped as a result of resolving defect report 550. Enabling C++0x/C++11 support actually removes the overloads in the libstdc++ implementation which could explain why you did not see any improvement.
Anyhow, it is probably a bad idea to rely on the accuracy of such a function especially if a conversion to integer is involved. A slight error towards zero will obviously make a big difference if you expect a floating point value that is an integer (like 100) and then convert it to an int-type value. So my suggestion would be write your own pow function that takes all integers or take special care with respect to the double->int conversion using your own round function so that a slight error torwards zero does not change the result.
Your problem is not a bug in gcc, that's absolutely certain. It may be a bug in the implementation of pow, but I think your problem is really simply the fact that you are using pow which gives an imprecise floating point result (because it is implemented as something like exp(power * log(base)); and log(base) is never going to be absolutely accurate [unless base is a power of e].
Consider the following piece of code:
#include <iostream>
#include <cmath>
int main() {
int i = 23;
int j = 1;
int base = 10;
int k = 2;
i += j * pow(base, k);
std::cout << i << std::endl;
}
It outputs "122" instead of "123". Is it a bug in g++ 4.7.2 (MinGW, Windows XP)?
std::pow() works with floating point numbers, which do not have infinite precision, and probably the implementation of the Standard Library you are using implements pow() in a (poor) way that makes this lack of infinite precision become relevant.
However, you could easily define your own version that works with integers. In C++11, you can even make it constexpr (so that the result could be computed at compile-time when possible):
constexpr int int_pow(int b, int e)
{
return (e == 0) ? 1 : b * int_pow(b, e - 1);
}
Here is a live example.
Tail-recursive form (credits to Dan Nissenbaum):
constexpr int int_pow(int b, int e, int res = 1)
{
return (e == 0) ? res : int_pow(b, e - 1, b * res);
}
All the other answers so far miss or dance around the one and only problem in the question:
The pow in your C++ implementation is poor quality. It returns an inaccurate answer when there is no need to.
Get a better C++ implementation, or at least replace the math functions in it. The one pointed to by Pascal Cuoq is good.
Not with mine at least:
$ g++ --version | head -1
g++ (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2)
$ ./a.out
123
IDEone is also running version 4.7.2 and gives 123.
Signatures of pow() from http://www.cplusplus.com/reference/cmath/pow/
double pow ( double base, double exponent );
long double pow ( long double base, long double exponent );
float pow ( float base, float exponent );
double pow ( double base, int exponent );
long double pow ( long double base, int exponent );
You should set double base = 10.0; and double i = 23.0.
If you simply write
#include <iostream>
#include <cmath>
int main() {
int i = 23;
int j = 1;
int base = 10;
int k = 2;
i += j * pow(base, k);
std::cout << i << std::endl;
}
what do you think is pow supposed to refer to? The C++ standard does not even guarantee that after including cmath you'll have a pow function at global scope.
Keep in mind that all the overloads are at least in the std namespace. There is are pow functions that take an integer exponent and there are pow functions that take floating point exponents. It is quite possible that your C++ implementation only declares the C pow function at global scope. This function takes a floating point exponent. The thing is that this function is likely to have a couple of approximation and rounding errors. For example, one possible way of implementing that function is:
double pow(double base, double power)
{
return exp(log(base)*power);
}
It's quite possible that pow(10.0,2.0) yields something like 99.99999999992543453265 due to rounding and approximation errors. Combined with the fact that floating point to integer conversion yields the number before the decimal point this explains your result of 122 because 99+3=122.
Try using an overload of pow which takes an integer exponent and/or do some proper rounding from float to int. The overload taking an integer exponent might give you the exact result for 10 to the 2nd power.
Edit:
As you pointed out, trying to use the std::pow(double,int) overload also seems to yield a value slightly less 100. I took the time to check the ISO standards and the libstdc++ implementation to see that starting with C++11 the overloads taking integer exponents have been dropped as a result of resolving defect report 550. Enabling C++0x/C++11 support actually removes the overloads in the libstdc++ implementation which could explain why you did not see any improvement.
Anyhow, it is probably a bad idea to rely on the accuracy of such a function especially if a conversion to integer is involved. A slight error towards zero will obviously make a big difference if you expect a floating point value that is an integer (like 100) and then convert it to an int-type value. So my suggestion would be write your own pow function that takes all integers or take special care with respect to the double->int conversion using your own round function so that a slight error torwards zero does not change the result.
Your problem is not a bug in gcc, that's absolutely certain. It may be a bug in the implementation of pow, but I think your problem is really simply the fact that you are using pow which gives an imprecise floating point result (because it is implemented as something like exp(power * log(base)); and log(base) is never going to be absolutely accurate [unless base is a power of e].
Consider the following piece of code:
#include <iostream>
#include <cmath>
int main() {
int i = 23;
int j = 1;
int base = 10;
int k = 2;
i += j * pow(base, k);
std::cout << i << std::endl;
}
It outputs "122" instead of "123". Is it a bug in g++ 4.7.2 (MinGW, Windows XP)?
std::pow() works with floating point numbers, which do not have infinite precision, and probably the implementation of the Standard Library you are using implements pow() in a (poor) way that makes this lack of infinite precision become relevant.
However, you could easily define your own version that works with integers. In C++11, you can even make it constexpr (so that the result could be computed at compile-time when possible):
constexpr int int_pow(int b, int e)
{
return (e == 0) ? 1 : b * int_pow(b, e - 1);
}
Here is a live example.
Tail-recursive form (credits to Dan Nissenbaum):
constexpr int int_pow(int b, int e, int res = 1)
{
return (e == 0) ? res : int_pow(b, e - 1, b * res);
}
All the other answers so far miss or dance around the one and only problem in the question:
The pow in your C++ implementation is poor quality. It returns an inaccurate answer when there is no need to.
Get a better C++ implementation, or at least replace the math functions in it. The one pointed to by Pascal Cuoq is good.
Not with mine at least:
$ g++ --version | head -1
g++ (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2)
$ ./a.out
123
IDEone is also running version 4.7.2 and gives 123.
Signatures of pow() from http://www.cplusplus.com/reference/cmath/pow/
double pow ( double base, double exponent );
long double pow ( long double base, long double exponent );
float pow ( float base, float exponent );
double pow ( double base, int exponent );
long double pow ( long double base, int exponent );
You should set double base = 10.0; and double i = 23.0.
If you simply write
#include <iostream>
#include <cmath>
int main() {
int i = 23;
int j = 1;
int base = 10;
int k = 2;
i += j * pow(base, k);
std::cout << i << std::endl;
}
what do you think is pow supposed to refer to? The C++ standard does not even guarantee that after including cmath you'll have a pow function at global scope.
Keep in mind that all the overloads are at least in the std namespace. There is are pow functions that take an integer exponent and there are pow functions that take floating point exponents. It is quite possible that your C++ implementation only declares the C pow function at global scope. This function takes a floating point exponent. The thing is that this function is likely to have a couple of approximation and rounding errors. For example, one possible way of implementing that function is:
double pow(double base, double power)
{
return exp(log(base)*power);
}
It's quite possible that pow(10.0,2.0) yields something like 99.99999999992543453265 due to rounding and approximation errors. Combined with the fact that floating point to integer conversion yields the number before the decimal point this explains your result of 122 because 99+3=122.
Try using an overload of pow which takes an integer exponent and/or do some proper rounding from float to int. The overload taking an integer exponent might give you the exact result for 10 to the 2nd power.
Edit:
As you pointed out, trying to use the std::pow(double,int) overload also seems to yield a value slightly less 100. I took the time to check the ISO standards and the libstdc++ implementation to see that starting with C++11 the overloads taking integer exponents have been dropped as a result of resolving defect report 550. Enabling C++0x/C++11 support actually removes the overloads in the libstdc++ implementation which could explain why you did not see any improvement.
Anyhow, it is probably a bad idea to rely on the accuracy of such a function especially if a conversion to integer is involved. A slight error towards zero will obviously make a big difference if you expect a floating point value that is an integer (like 100) and then convert it to an int-type value. So my suggestion would be write your own pow function that takes all integers or take special care with respect to the double->int conversion using your own round function so that a slight error torwards zero does not change the result.
Your problem is not a bug in gcc, that's absolutely certain. It may be a bug in the implementation of pow, but I think your problem is really simply the fact that you are using pow which gives an imprecise floating point result (because it is implemented as something like exp(power * log(base)); and log(base) is never going to be absolutely accurate [unless base is a power of e].
My problem is somewhere in the definition of first_x and second_x. When I call the quad_eq function, I get a -nan(ind) return based on the code below. If I change the .pushback() method parameter to be a literal integer, I get that integer returned instead of NaN. This leads me to believe that the problem is with my calculation/definition of first_x and second_x. Maybe there is some trick to C++ that I am not seeing or understanding. Can anyone see what my problem is? (If this helps I am working out of Bjarne Stroustrup's C++ Principles and Practice Using C++ where he gives me the std_lib_facilities.h file to use as I do not understand headers yet)
vector<double>quad_eq(double a, double b, double c) {
vector<double>answers;
double first_x = (-b + sqrt((b * 2) - (4 * a * c))) / 2 * a;
double second_x = (-b - sqrt((b * 2) - (4 * a * c))) / 2 * a;
answers.push_back(first_x);
answers.push_back(second_x);
return answers;
}
Depending on the input, you are taking the square root of negative numbers, so you get NaN (which is, in fact, a double) out of that, and any other operations propagate that.
Sidenote: the code you show doesn't compile as-is, because it is missing #include <vector> and using namespace std;. The latter is also usually frowned upon.
int a = 0, b, c, e, n = 25;
e = n;
while(n!=0)
{
n=n/10;
a++;
}
printf("%d",a);
b = e * e;
c = b % (pow(10, a));
if(c==e)
printf("automorphic");
For the line
c=b%(pow(10,a));
the compiler shows an error:
invalid operands of types `int' and `double' to binary `operator%'
pow returns a double, and you can't use % on doubles.
pow returns a double, which you cannot use as operator for the %.
Try:
c=b%((int)pow(10,a));
instead.
As per other answers: pow introduces doubles into your program, and then you hvave to convert them back to ints.
Best to avoid the problem, then:
int a = 1;
while(n!=0)
{
n=n/10;
a *= 10;
}
a /= 10;
b=e*e;
c=b%a;
(Edit) I marked a line "Fishy" because what happens with n=0..9? You probably need
while (n >= 10)
..
(Edit again, sigh) Sorry -- above edit is wrong, you need the total number of digits. a needs adjusting after the loop.
The % operator can be operated only with integers. pow function returns a double and that's why you are getting error.
In C/C++ the modulus operator (%) is limited to integers. You can use fmod (...) for floating-point modulus but you still need to match types to use that. So you are going to have to cast one of your variables or expressions no matter which solution you chose to use; I would use integer modulus personally.
This is in contrast to languages like Java and C#, which allow you to have an integer on one side of the modulus operator and a float on the other with no problems. This can be a source of portability headaches when porting from other languages into C.
The code can be corrected as:
int a = 0, b, c, e, n = 25;
e = n;
while(n!=0)
{
n=n/10;
a++;
}
printf("%d",a);
b = e * e;
/*
call to pow() function returns a double value and b is an integer type variable.
For any operation (here, modular division) the operands must be of same type.
So, the double value returned from call to pow() function must be explicitly
casted to int type as shown in the code below. Also, the first argument to pow()
must to be double (or, float) type. Here, 10 is integer type, correct it as 10.0.
The result will be fine.
*/
c = b % (int)(pow(10.0, a));
if(c==e)
printf("automorphic");