C Programming: acos() not accepting variable

AI Thread Summary
The discussion centers on the use of the acos() function in C programming, specifically regarding its acceptance of variables. The primary issue arises from integer division, where dividing two integers results in an integer, leading to unexpected outputs when passed to acos(). For example, using acos(i/2) with i as an integer results in 0 instead of the expected 0.5, which is necessary for correct calculations. It is suggested to use a floating-point division, such as acos(i/2.0), to achieve the desired result. The conversation emphasizes the importance of understanding data types and the potential for compiler-related issues when using outdated compilers.
angelspikes
Messages
10
Reaction score
0
The following function acos() does not accept any variables.
I have included the math.h header.

For example
i = 1;

acos(i/2); // This should be equal to 60
 
Technology news on Phys.org
I take it we're supposed to guess what kind of error message you get and whether you get it a compile time or run time?
 
Is i declared as an integer? Integer divided by integer gives an integer as its result. I'd be surprised if acos() accepts an integer as its argument.

Hmmm... according to http://www.cplusplus.com/reference/cmath/acos/, in C++11, acos() does have "additional overloads for integral types". Still, integer division of 1/2 gives 0 as its result, so even if you were using C++11 and the compiler accepted it, you might not like the result anyway!
 
angelspikes said:
acos(i/2); // This should be equal to 60

To add to what was already posted - it shouldn't return 60. It should return something close to 1.047.
 
Here's a refernce to the inverse trig functions:

http://www.gnu.org/software/libc/manual/html_node/Inverse-Trig-Functions.html#Inverse-Trig-Functions

from it you can see the input to acos() is a double and the output is a double value of the angle in radian measure

you intended to input 0.5 and expected to get 60 degrees. but 1/2 = 0 via integer division and so you should get a radian measure of pi/2 or 1.57 radians.

you should try coding it as acos(i/2.0) or something like that and see if you get the expected angle in radian measure.
 
Last edited by a moderator:
phinds said:
I take it we're supposed to guess what kind of error message you get and whether you get it a compile time or run time?

Yes, it's one of those days.
 
jtbell said:
Is i declared as an integer? Integer divided by integer gives an integer as its result. I'd be surprised if acos() accepts an integer as its argument.

Hmmm... according to http://www.cplusplus.com/reference/cmath/acos/, in C++11, acos() does have "additional overloads for integral types". Still, integer division of 1/2 gives 0 as its result, so even if you were using C++11 and the compiler accepted it, you might not like the result anyway!

No matter what data type I use, even float, will return acos(variable) as an error.
 
Perhaps we can uncover the problem by being more specific

Code:
% cat acos.c

#include <math.h>
double acos(double x);

main()
{
double y;
y=0.0;
printf("%f\n", acos(y));
y=0.5;
printf("%f\n", acos(y));
y=1.0;
printf("%f\n", acos(y));
}

% cc acos.c -lm

% a.out

1.570796
1.047198
0.000000

So can you reproduce exactly these steps and post exactly what you got out?
I did cheat slightly by inserting a blank line between each of my lines, but changed nothing else.
And that was run under FreeBSD with the supplied cc version 2.95.4.

With gcc I get

Code:
% gcc acos.c -lm
% a.out
1.570796
1.047198
0.000000

but the gcc also reports version 2.95.4 so they are probably aliased to be the same thing at some level.
 
Last edited:
angelspikes said:
No matter what data type I use, even float, will return acos(variable) as an error.

How about any other math functions?

Remember, the more information you provide, the quicker we can help resolve your problem, even if it is 'one of those days.'
 
  • #10
angelspikes said:
No matter what data type I use, even float, will return acos(variable) as an error.
Meaning what? You need to be specific when asking about programming errors. You also need to realize that the error is almost certainly yours. The number of times I thought I had run into a compiler or linker bug in my 40+ years programming: Countless. The number I've run into a true compiler or linker bug: Very, very few. The error is almost always mine.

Does your program fail to compile, fail to link, or fail at runtime? What exactly do you mean by "will return acos(variable) as an error"?
 
  • #11
Bill Simpson said:
And that was run under FreeBSD with the supplied cc version 2.95.4.
Oh. My.

Get a new compiler! gcc 2.95 is a compiler written in some previous millennium. There is *no* excuse to be using a buggy free compiler from some previous millennium when you can get a very good free compiler from this decade.
 
  • #12
My only purpose was to try to get the original poster to provide detailed information about exactly what he had done.
 
Last edited:
  • #13
jtbell said:
Is i declared as an integer? Integer divided by integer gives an integer as its result. I'd be surprised if acos() accepts an integer as its argument.

It doesn't accept an integer (assuming the OP included a header file that declared it properly, of course!)

But every version of C from the beginning knew how to convert integers to doubles. The problem is that it evaluates i/2 as an integer expression and THEN converts the result to double.

Hmmm... according to http://www.cplusplus.com/reference/cmath/acos/, in C++11, acos() does have "additional overloads for integral types".

That's irrelevant to the question. C++11 has some new features so you can tell the compiler that a user-defined type (class) behaves the same way as the built-in integer types, etc. The more the compiler "knows" about the semantics of the code, the more optimization it can do. But "a class that behaves like an integer" is not exactly the same as "an integer", so the "additional overloads" are giving the compiler yet more information.
 

Similar threads

Back
Top