macOS Cosine (Degrees and Radians)

[forrestgrant]

Hi there, I have a function in my objective c project that plays with sine and cosine... basically:

float y;
float x;
x = 85.09 //any number really
y = cos(x);

The problem is that by default, xcode (or objective c, im not entirely sure which) uses Radians to graph a cosine wave. But I want my answer to come back in degrees. I know all about how to mathematically convert a radian to a degree and vice versa. But for the purpose of actually graphing something, I would love to actually create a cosine wave in degrees. Any ideas?

 

[lee1210]

I don't think this is provided by anything in the C standard library math.h. I don't know about any Cocoa frameworks that provide the functionality you're looking for. It's probably best to just make a function CosDegrees or something similar and use cos from math.h and do the manipulation yourself.

-Lee

 

[kalimba]

In the example you posted, it appears that the angle value you're passing is meant to be in degrees. The standard C trig functions accept angle parameters in radians, so all you'd need to do is convert your value in degrees to radians before passing to the cos() [or sin(), or whatever] function.

In the past, I've written my own helper functions (or macros) to do these conversions for me -- RAD2DEG() and DEG2RAD() would be what I recommend.

 

[swiftaw]

or, just change the last line to y = cos(2*pi*x/360)

 

[kalimba]

or, just change the last line to y = cos(2*pi*x/360)

Additionally, if you're concerned about (partial) optimization, you could rewrite this as:

y = cos( pi * x / 180 );

And it's possible to optimize this even further!

 

[forrestgrant]

cool, looks like that worked. I knew how to convert degrees to radians, I did not know doing it inside the function would change the entire wave.

 

[Sayer]

cool, looks like that worked. I knew how to convert degrees to radians, I did not know doing it inside the function would change the entire wave.

Uh, cosine and sine are both radians-based so yeah they would be different if you passed in Degrees.

 

[Sander]

Additionally, if you're concerned about (partial) optimization, you could rewrite this as:

y = cos( pi * x / 180 );

And it's possible to optimize this even further!

I'm pretty sure these constant expressions are eliminated at compile-time. So always write down stuff you can understand later, when you re-read your own code. Don't pre-calculate 2pi/360 yourself and insert that magic number everywhere.

 

[SPUY767]

Additionally, if you're concerned about (partial) optimization, you could rewrite this as:

y = cos( pi * x / 180 );

And it's possible to optimize this even further!

CGFloat DegreesToRadians(CGFloat degrees) {return degrees * M_PI / 180;};

That line right after your import statements should register that method which should run as fast as something called from the core foundation library without the overhead of a traditional function call to the class itself.

 

[Sander]

CGFloat DegreesToRadians(CGFloat degrees) {return degrees * M_PI / 180;};

That line right after your import statements should register that method which should run as fast as something called from the core foundation library without the overhead of a traditional function call to the class itself.

That's hoping it gets inlined, which is not guaranteed. Besides, why use CGFloat instead of plain old float (or better still, double)?

 

[lazydog]

Hi
You can define the conversion once using a macro, something like this:-

#define RADIANS( degrees ) ( degrees * M_PI / 180 )
...
...
y = cos( RADIANS(x) ) ;

b e n

 

[JVene]

In the early days of PC game programming (middle 80's), we used a trick in assembler that you might consider for specialized situations.

If you need considerable accuracy, this won't work.

For early games, we often simplified angles to 1 degree or .5 degree increments. The sin and cos functions from trig are calculated by a number of means (including, say, polynomial approximations) - but there was a time when most of us used a chart - and that's what was often done in the early games.

For 1 degree increments, we created an array for sine, populated each entry in the array with the value of sine for each degree (or, at twice the size, each half degree) - and simply referenced the entry in the array AS the angle in degrees.

This was usually done for the old 386 (and it's ancestors), which didn't have floating point hardware. It's not as much of a speed enhancement today as it was way back when, and I offer the approach only as a view into how this problem was handled under a specialized circumstance.

However, you should consider if there's a performance issue or not. The division takes some time, and if you are concerned about performance, you may find that the user perspective (of degrees) is a display or presentation only, and make the conversion from radians TO degrees for display and input, because it is more common that supplying the 'native' radians to the sin/cos functions is faster because that's more dense processing.