Computing sin(x) from cos(x)

puffpio

Golden Member
Dec 21, 1999
1,664
0
0
I'm given a value of cos(x) and I want to find sin(x)

There are two ways I can think of, but which way takes less CPU time..and are there even better ways that save time?

Given:
double cosX = some number;

1)

double sinX = sin(invCos(cosX));

2)

double sinX = sqrt(1 - cosX * cosX);

-------------

i dunno what goes on inside of invCos() and sin() functions (lets assumg C++ here)
or what goes on inside sqrt()...

Or are there even more efficient ways to calculate/optimize this?
 

Drakkon

Diamond Member
Aug 14, 2001
8,401
1
0
what about cos(pi/2-x) = sin(x) or do you not have the ability to modify cosX?
If you cant modify cosX then you should have an equal amount of operations between the 2 so it would come down to the language and if one handles sqrt better than it handles sin.
 

aCynic2

Senior member
Apr 28, 2007
710
0
0
Originally posted by: Drakkon
what about cos(pi/2-x) = sin(x) or do you not have the ability to modify cosX?
If you cant modify cosX then you should have an equal amount of operations between the 2 so it would come down to the language and if one handles sqrt better than it handles sin.


I would use this method. In brief, the parameter values of Cos = Sin phase shifted pi/2 produce the same results.

Sin(0) = Cos(pi/2) so by the golden rule:

Sin (pi/2) = Cos(2pi)

Look here:

http://www.geocities.com/mathf.../school/trig/trig0.htm
 

puffpio

Golden Member
Dec 21, 1999
1,664
0
0
well i dont have X i only have the value of cos (x)
if I did cos(pi / 2 - x) I would have to do a invcos(cosX)
then I might as well just do sin() of that result.

I was wondering if there was a sneaky way of not having to calculate back X..or another way that is not CPU intensive
 

aCynic2

Senior member
Apr 28, 2007
710
0
0
Originally posted by: puffpio
well i dont have X i only have the value of cos (x)
if I did cos(pi / 2 - x) I would have to do a invcos(cosX)
then I might as well just do sin() of that result.

I was wondering if there was a sneaky way of not having to calculate back X..or another way that is not CPU intensive

Ok, let me see if I'm follwing:

Given the functions:

f(x1) = sin(x1)
g(x2) = cos(x2)

Are you wanting to find

x1 or f(x1) ?

when you have

x2 or g(x2)?

I had to distinguish between x1 and x2 because if you have x, you don't need to find it. sin(x) != cos (x), but sin(x) == cos(x+pi/2).
 

CTho9305

Elite Member
Jul 26, 2000
9,214
1
81
I would expect 2 to be significantly faster. According to this document fsin is 96-192 cycles, while fsqrt is 19 or 27 or 35 cycles, and a multiply is 4 cycles. That's if it's compiling to x86 floating point sin instructions, though, rather than using a software lookup table. Write a loop that does each method 1 million times and see how long it takes, though.
 

aCynic2

Senior member
Apr 28, 2007
710
0
0
Originally posted by: CTho9305
I would expect 2 to be significantly faster. According to this document fsin is 96-192 cycles, while fsqrt is 19 or 27 or 35 cycles, and a multiply is 4 cycles. That's if it's compiling to x86 floating point sin instructions, though, rather than using a software lookup table. Write a loop that does each method 1 million times and see how long it takes, though.

Do they use lookup tables anymore with processors where they are now? I can see the value still, if we're talking about a need for absolute and utter speed, but it's seems 80% of programming doesn't need that kind of speed. They're affected more by development time.

Also, anything newer than that document? It's > 5 yrs old.
 

CTho9305

Elite Member
Jul 26, 2000
9,214
1
81
Originally posted by: aCynic2
Originally posted by: CTho9305
I would expect 2 to be significantly faster. According to this document fsin is 96-192 cycles, while fsqrt is 19 or 27 or 35 cycles, and a multiply is 4 cycles. That's if it's compiling to x86 floating point sin instructions, though, rather than using a software lookup table. Write a loop that does each method 1 million times and see how long it takes, though.

Do they use lookup tables anymore with processors where they are now? I can see the value still, if we're talking about a need for absolute and utter speed, but it's seems 80% of programming doesn't need that kind of speed. They're affected more by development time.

Well, the LUT could be in a library provided with the compiler. I don't know, which is why I said, "if" ;)

Also, anything newer than that document? It's > 5 yrs old.
The age doesn't really matter - stuff like this won't really change much between a first-release K7 and a last-release K7 (ignoring performance boosts you could get with new features e.g. SSE). This document is for K8, and this one is for Barcelona/Phenom. I don't think much floating point stuff changed between K7 and K8 though (ignoring SSE stuff). IIRC the K8 and Barcelona docs don't have handy cycle count charts, which is why I pointed you to the K7 guide initially.

edit: fixed links
edit2: I was wrong, the cycle counts are in the newer docs too. FSIN is 93 cycles on K8, FSQRT is 35. FMUL is 4. I'd suggest checking what instructions your code compiles to, because I'm not very familiar with x87 assembly so there may be a better way to do this. If you happen to be computing the cos yourself and just want to get the sin fast, there's an FSINCOS instruction that computes both at once and would probably be the fastest choice.
 

aCynic2

Senior member
Apr 28, 2007
710
0
0
Originally posted by: CTho9305
edit: fixed links
edit2: I was wrong, the cycle counts are in the newer docs too. FSIN is 93 cycles on K8, FSQRT is 35. FMUL is 4. I'd suggest checking what instructions your code compiles to, because I'm not very familiar with x87 assembly so there may be a better way to do this. If you happen to be computing the cos yourself and just want to get the sin fast, there's an FSINCOS instruction that computes both at once and would probably be the fastest choice.

I really kind of miss the days of programming in assembly. It would really so occupy your time, working out the puzzle.