sine and cosine

[Dennis]

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

Math.cos(Math.toRadians(degrees)) works to 269
Math.sin(Math.toRadians(degrees)) works to 179

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

[Fubarable]

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.

[JosAH]

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

[pbrockway2]

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"?

[al_Marshy_1981]

would dividing a value into Math.PI help here?

[pbrockway2]

That's what toRadians() does: conceptually, it divides its argument into 180*Math.PI.

[al_Marshy_1981]

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

[pbrockway2]

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.

[al_Marshy_1981]

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?

[pbrockway2]

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...