1. ## sine and cosine

I wanna create a program how to calculate the sine and cosine of a degree.

cos of 269 = -0.017452406437283498
cos of 270 = -1.8369701987210297E-16 (WRONG)

sin of 179 = 0.01745240643728344
sin of 180 = 1.2246467991473532E-16 (WRONG)

Does someone know how I can create a working sin/cos function to infinite?

Thanks,
Dennis

2. What you label as WRONG is actually correct within the limitations of use of floating point numbers. I think that you will want to Google and read up on and understand the limitations of working with floating point numbers.

3. Originally Posted by Dennis
cos of 270 = -1.8369701987210297E-16 (WRONG)
sin of 180 = 1.2246467991473532E-16 (WRONG)
Read Goldberg's article: What every computer scientist should know about floating point arithmetic.

kind regards,

Jos

4. Moderator
Join Date
Feb 2009
Location
New Zealand
Posts
4,712
Rep Power
14
I think that you will want to Google and read up on and understand the limitations of working with floating point numbers

I agree.

It might seem trivial: but there are only a finite number of different values that can be assigned to a double. And there are an infinite number of real numbers even over the range [-1,1] of the sine function. (And all of them are the sine of something).

The best a computer might do is produce one of the values a double might have that is "close" to the mathematical result. The exact promises of the Math class in this regard are documented in its API documentation.

Note that it doesn't promise (in the case of sine) the very closest double (what it calls "correctly rounded"). And, anyway, the toRadians(180) produces a double value that is, at best, close to a well known real numeric value. toRadians() "Converts an angle measured in degrees to an approximately equivalent angle measured in radians. The conversion from degrees to radians is generally inexact." Not very awe inspiring! But, as always, the API docs are the defintion of correctness.

(The business of ulps used in the API documentation is discussed and explained in the Goldberg paper linked to.)

Another point: we humans notice the oddity with sin(180) and declare it "WRONG". But what about sin(179)? Your lack of comment on the displayed value might well be taken as endorsement, but have you really verified that it is, in some significant sense, "RIGHT"?

5. Senior Member
Join Date
Feb 2010
Location
Waterford, Ireland
Posts
748
Rep Power
7
would dividing a value into Math.PI help here?

6. Moderator
Join Date
Feb 2009
Location
New Zealand
Posts
4,712
Rep Power
14
That's what toRadians() does: conceptually, it divides its argument into 180*Math.PI.

7. Senior Member
Join Date
Feb 2010
Location
Waterford, Ireland
Posts
748
Rep Power
7
Java works in radians not degrees though right? or am I losing it again :D

edit: leaving my original dumb post lol thanks for the info pbrockway2

8. Moderator
Join Date
Feb 2009
Location
New Zealand
Posts
4,712
Rep Power
14
Yes Math.sin() wants a radians argument. But the OP is working in degrees, so he calls Math.toRadians(arg) first which does something like 180*Math.PI/arg and then calls Math.sin() with the result.

The OP's problem, though, was not understanding why the output obtained was very very close but not exactly the same as the mathematical sin function.

9. Senior Member
Join Date
Feb 2010
Location
Waterford, Ireland
Posts
748
Rep Power
7
Okay thanks for the feedback pbrockway, my maths for graphics course refuses to allow us to use built in functions (so you can imagine implementing it) not too bad for converting degrees to radians though.

Is the OP post an easy fix though?

10. Moderator
Join Date
Feb 2009
Location
New Zealand
Posts
4,712
Rep Power
14
my maths for graphics course refuses to allow us to use built in functions (so you can imagine implementing it)

Ouch! It's the sort of thing I would try and not imagine ;)

The OP's (code) fix is extremely easy: do nothing. The output he posted is correct. He just needs to accept it (*). Understanding why it's correct (the brain fix) is another matter and I guess he has hasn't responded because he's away somewhere reading the Goldberg paper.

* I have seen posts involving freaky things happening with Java graphics whose cause turned out to be floating point gotchas. (can't remember the details offhand) The solution is to rearrange the maths to avoid the problem. AGain, I'd prefer to imagine someone else doing the numerical calculations...

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•