sine of an angle in degree mode

[rflesch]

On the classic HP calculators, in degree mode, sin(180) is exactly equal to zero, and I don't understand why:
(a) angles are internally represented in units of radians as far as I know;
(b) the sine function is a transcendental function; whatever algorithm is used, it cannot give us the exact result in a finite number of steps.
Both (a) and (b) should lead to a small deviation from zero.

[Paul Dale]

Any moderately decent code for the trig functions deals with the right angles regardless of the mode: i.e. sin(90°), sin(180°), sin(270°), sin(360°), sin(100G), sin(200G), sin(300G), sin(400g).

Radians might be perfect for computation, however many uneducated people disagree (from ignorance). Reasonable implementations deal with the symmetry about the right angles. It is impossible to disagree with this decision and hard to match it.


Pauli

[rflesch]

Oh! sine(180) is not calculated - there is a lookup table for special values such as right angles?

[rflesch]

If there is a lookup table, pi/2 etc. could be included as well.
sine(pi) is treated differently from sine(180), on the 15C at least.

[Werner]

SIN(180°) is zero because that is the exact result - contrary to Pi, 180 is exactly representable, and so an exact result can be given.
SIN and COS in degrees are first reduced to the interval 0°-45° before converting to radians, which can be done without introducing errors (the reduction I mean), meaning SIN(180°) is reduced to SIN(0°) = 0.
SIN(Pi) is also zero, and for CAS-enabled calculators that is the result given. In dealing with real numbers, Pi is no longer exactly representable, but is rather rounded to the calculator's precision, and you calculate
SIN(3.14159265359), which is NOT SIN(Pi). And since SIN(Pi - x) = SIN(x) ~= x for very small x, that is what you get.

Cheers, Werner

[emece67]

(01-24-2018 10:04 AM)rflesch Wrote:  If there is a lookup table, pi/2 etc. could be included as well.
sine(pi) is treated differently from sine(180), on the 15C at least.

The 15C does not manage the sin(pi) case. At most it manages the sin(3.141592654) case.

[BartDB]

So here's my take on it:

If the user enters sin(180) or sin(pi) where pi=symbol of pi
Then the programmer can assume they want the sin of exactly 180 degrees or pi radians.

However, if the numerical value of pi is used then sin(3.14159265359) is entered (showing 12-digit as per most HP calcs)
Then the question is: did the user really want the sin of exactly pi radians or did they want the sin of the approximated value?
As the programmer cannot pre-empt this, the best approach is to provide the answer of the approximated value.

Of course some calculators try to second-guess this and this can lead some interesting answers.

EDIT: note on HP calculators pi is interpreted to its numerical value unless CAS is used if it exists (e.g. Prime CAS mode or 50g symbolic mode).

[Thomas Okken]

(01-24-2018 10:25 AM)emece67 Wrote:  

(01-24-2018 10:04 AM)rflesch Wrote:  If there is a lookup table, pi/2 etc. could be included as well.
sine(pi) is treated differently from sine(180), on the 15C at least.

The 15C does not manage the sin(pi) case. At most it manages the sin(3.141592654) case.

I don't have a 15C handy to check, but for what it's worth, on the HP-41, sin(3.141592654) returns -4.1e-10, which indicates that it reduces the argument using a 12-digit approximation of pi (*). In fact, the sequence PI SIN is a good way to find out how many digits of pi a calculator uses for angle reduction in radians.

If PI SIN returns 0, you're either using CAS or the internal version of pi has the same number of digits as the PI function on the keyboard.

(*) Or 13-digit, which would lead to the same result: -4.10e-10 vs. -4.1e-10.

[rflesch]

Of course, 90 deg is exactly a right angle, whereas a calculator cannot represent a right angle exactly by using radians.
So - the argument of the sine function of a right angle (in degrees!) is exact, but the algorithm that calculates the function value of this argument cannot be exact as far as I can see. I would assume that no algorithm in the known galaxy could calculate sin(180deg) exactly, because the value is a real number, i.e. "0.00000(...)". I would greatly appreciate if somebody could tell me if I am wrong here.

[rflesch]

Thomas Okken wrote:
"If PI SIN returns 0, you're either using CAS or the internal version of pi has the same number of digits as the PI function on the keyboard.

— I don't understand the second part of this sentence. If the internal representation of pi has the same number of digits as as the PI function on the keyboard then I would get zero as a result of SIN PI??

On the 15C, "PI SIN" gives "-4.1E-10" (indicating the CORDIC algorithm with 10 digits is used).
Aren't there two sources of error in the result that's displayed:
(a) the finite number of digits of the internal representation of pi;
(b) the approximative character of the algorithm?
So I would think that "-4.1E-10" is not exactly the sine of the internal representation of pi in the calculator.

[Werner]

Well of course it can, and I've already told you:
SIN(180°) is reduced to SIN(0°), which is converted to 0 radians, the sine of which is exactly zero. That's one part of the algorithm for you. And I can assure you that that's how it is programmed.
Werner

[rflesch]

Werner, thank you.
"Well of course it can, and I've already told you

Please why is "zero" as an argument of the function so special? Why does an algorithm give me an exact function value if the argument is zero? (Unless the algorithm cheats on me and treats zero different from other numbers)

[Thomas Okken]

(01-24-2018 12:06 PM)rflesch Wrote:  I would assume that no algorithm in the known galaxy could calculate sin(180deg) exactly, because the value is a real number, i.e. "0.00000(...)". I would greatly appreciate if somebody could tell me if I am wrong here.

You are wrong.

You don't appear to be familiar with the concept of argument reduction.

The trigonometric functions are all periodic, meaning sin(x) = sin (x + 2 * n * pi), for all x ∈ R and all n ∈ Z, and similar for cos, tan, etc.

Since the algorithms used to calculate these functions are all iterative with rapid convergence only within a narrow interval, the identity above is used to reduce the argument, by taking its remainder modulo 2pi, or, in degrees, modulo 360. In radians, this reduction cannot be exact in finite precision, because of the irrationality of pi, but in degrees, it is exact.

Within the range 0 to 2pi, or 0 to 360°, the argument can be reduced further, by using trigonometric identities like sin(x) = sin(pi - x), which are also exact when performed in degrees.

The end result is that, through argument reduction, all those special values you mentioned are reduced to exactly zero, without any of them actually being treated as a special case.

[Thomas Okken]

(01-24-2018 12:26 PM)rflesch Wrote:  Please why is "zero" as an argument of the function so special? Why does an algorithm give me an exact function value if the argument is zero? (Unless the algorithm cheats on me and treats zero different from other numbers)

What, you don't know why the sine of zero is zero? Do you know anything about trigonometrics at all?

[rflesch]

"What, you don't know why the sine of zero is zero?
Sorry Thomas I did not want to bother you. I assume we all know what the sine of zero is.
Question is, how does the algorithm used in a calculator 'know' that it's exactly zero.

[Thomas Okken]

(01-24-2018 12:37 PM)rflesch Wrote:  how does the algorithm used in a calculator 'know' that it's exactly zero.

The same way the algorithm "knows" the result for any argument: by performing a calculation. Plug in a number, perform a series of steps, and hey presto, you have a result. Take a sine algorithm, plug in zero, you get zero. That's all there is to it, what else were you thinking of?

Now, a sine algorithm might recognize zero, treat it as a special case, and return zero immediately, rather than going to the usual sequence of steps. If you want to call that "cheating," go right ahead, but most of us would call it a performance optimization: same result, only faster.

[emece67]

(01-24-2018 12:37 PM)rflesch Wrote:  "What, you don't know why the sine of zero is zero?
Sorry Thomas I did not want to bother you. I assume we all know what the sine of zero is.
Question is, how does the algorithm used in a calculator 'know' that it's exactly zero.

The sine function is an odd function. In case you use a polynomial of some degree to approximate it, such polynomial p(x) may be an odd function too, so it can have the form x*q(x), being q(x) another polynomial. Thus, if x is 0, the evaluation of the p(x) polynomial will be exactly 0, and the algorithm does not need to compute q(x) to know that.

The same may occur if the algorithm used is the CORDIC one.

In any case, the algorithm used inside the calculator to compute sines is not the barebones CORDIC or polynomial approximation, but a more complex algorithm that: reduces the argument to a smaller range; converts it to radians (perhaps checking for some special cases here); checks some special cases; and, eventually, executes the barebones CORDIC/polynomial or Padé or whatever approximation. So I think that the answer to the question "how does the algorithm used in a calculator 'know' that it's exactly zero" is "because the algorithm used explicitly checks if the argument is 0 and, if so, returns a 0".

Another example, how is that an integration algorithm knows that \(\int_a^af(x)dx=0\)?. Because, with a high probability, it explicitly checks if both limits are equal, being such the case it returns a 0.

Regards.

[AndiGer]

Have no real 15C at hand but Free 15C emulator for "bitten apple"
Sine in DEG for 360, 720, ... gives me a multiplier of the previous result without another 360 degrees added. Don't know it uses original firmware.

[cyrille de brébisson]

Hello,

All HP calcs use the same algo.
First, reduce the angle to 0/45°
Then transform to radian (inputs in degree mode are tested for special values such as 0, 360, 180, 90).
Use CORDIC
return results

Cyrille

[Thomas Okken]

(01-26-2018 05:43 AM)cyrille de brébisson Wrote:  Hello,

All HP calcs use the same algo.
First, reduce the angle to 0/45°
Then transform to radian (inputs in degree mode are tested for special values such as 0, 360, 180, 90).
Use CORDIC
return results

Cyrille

You seem to be contradicting yourself.

What happens first, the angle reduction to 0° to 45°, or the check for special values? How do you check for 360°, 180°, 90° after reducing to 0°...45°?

Sorry to be a pest, but since a decent fraction of this thread was precisely about these kinds of details, your post doesn't actually clear anything up.