Cosine (Degrees and Radians)

Discussion in 'Mac Programming' started by forrestgrant, Jun 27, 2008.

  1. macrumors member

    Jun 24, 2008
    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?
  2. macrumors 68040


    Jan 10, 2005
    Dallas, TX
    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.

  3. macrumors regular

    Jun 10, 2008
    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.
  4. macrumors 603


    Jan 31, 2005
    Omaha, NE, USA
    or, just change the last line to y = cos(2*pi*x/360)
  5. macrumors regular

    Jun 10, 2008
    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!
  6. thread starter macrumors member

    Jun 24, 2008
    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.
  7. macrumors 6502a


    Jan 4, 2002
    Austin, TX
    Uh, cosine and sine are both radians-based so yeah they would be different if you passed in Degrees.
  8. macrumors 6502

    Apr 24, 2008
    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.
  9. macrumors 68000


    Jun 22, 2003
    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.
  10. macrumors 6502

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

    Sep 3, 2005
    Cramlington, UK
    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
  12. macrumors newbie

    Jul 22, 2008
    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.

Share This Page