Taylor series for sin(x) doesn't give the right answer above 34 radians

I have the following code:

x=35;
N=90;
si=0;
for k = 0:N
    si = si +((((-1)^(k))*((x^(2*k+1))))/(factorial((2*k+1))));
end
fprintf(['actual value from the code ' num2str(si) '\n'])
fprintf(['actual value from sin (' num2str(x) ')= ' num2str(sin(x))])

I did examples from x=.1 to x=34, they give you almost approximation to the correct one or sometimes the exact value of sin(x) (note that I increase the N as we x becomes bigger, i.e. x=10, then N could be 15, but for x=20, then N could be at least 30 to find the exact value). But, when I try for x=35 or above and I increase N to reach 70 till 90, then it doesnt change. It looks like matlab give the same result for N=70 to N=90. If you choose N to be 120 or above, then matlab won't work, it gives NaN.

My question: If I want to perform a code like this one to find for x=35 and above, then how can I modify the code to do it? Or what other ways to do it.

Thanks

Answer 1

[Ameer Hamza]

The taylor series is only valid in radians

x=35*pi/180; % convert to radians. Or x = deg2rad(35).
N=90;
si=0;
for k = 0:N
    si = si +((((-1)^(k))*((x^(2*k+1))))/(factorial((2*k+1))));
end
fprintf('actual value from the code %f\n', si)
fprintf('actual value from sin (%f)= %f\n', x, sin(x))

[Yousef Mohammed]

Thank you Ameer, but I have an issue.

Let's say x=35, we convert it to radians, then we get: 0.610865

Now, by taylor series for sin(x), we get: 0.57358.

But If I run sin(35) in calculator, I got: -0.4281

Now, how to ensure that sin(0.610865) is the sin(35).

[Ameer Hamza]

Calculators also uses radians. If you actually meant 35 radian, then it is better to map them between -pi to pi as suggested by James

x=35; % convert to radians. Or x = deg2rad(35).
x = rem(x, 2*pi)-pi;
N=90;
si=0;
for k = 0:N
    si = si +((((-1)^(k))*((x^(2*k+1))))/(factorial((2*k+1))));
end
fprintf('actual value from the code %f\n', si)
fprintf('actual value from sin (%f)= %f\n', x, sin(x))

or alternatively, if you directly want to use 35 without mapping them, then you need to use higher precision mathematics using a symbolic toolbox. Fixed-precision floating-point has its limitations

syms k

x = 35;
N=90;
si = symsum((-1).^k.*x.^(2*k+1)./factorial(2*k+1), 0, N);
fprintf('actual value from the code %f\n', si)
fprintf('actual value from sin (%f)= %f\n', x, sin(x))

[Steven Lord]

Be careful. Are you and your calculator working in degrees or in radians?

angleD = 35 % 35 degrees
angleR = deg2rad(angleD) % 35 degrees in radians, about 0.61

sindDeg = sind(angleD) % sine of 35 degrees
sinRad = sin(angleR) % sine of about 0.61 radians

% Probably not what you want, but potentially what you were computing
sindRad = sind(angleR) % sine of about 0.61 degrees
sinDeg = sin(angleD) % sine of 35 radians

sindDeg and sinRad should be the same in a floating point sense. There's no reason to expect sindRad and sinDeg to be the same or for either to be the same as sindDeg or sinRad.

Answer 2

[James Tursa]

The larger x is, the more cancellation error you are going to get with the intermediate sums. It would be best to reduce the range of x to be within [-pi,+pi] first before feeding it to your Taylor Series.

[Yousef Mohammed]

Thank you James