Any thoughts?

Wrote

Any thoughts ?

It has nothing to do with Smath that displays Win Trig.

Wrote

It has nothing to do with Smath that displays Win Trig.

Not sure I follow...

Let me be more exact in my request.

Why is cos(270-deg) not equal to zero?

What can I do to make cos(270-deg) equal to zero?

I'll be honest, I'm a bit surprised this even an issue. Seems very basic.

sine of 360 is also not quite zero...

Wrote

I'll be honest, I'm a bit surprised this even an issue. Seems very basic.

Don't worry, other math programs may surprise you too. SMath, like many other programs, has two forms of calculation: numeric (=) and symbolic (Ctrl + dot). However, the SMath symbolic kernel is not well as others may be, but at least it almost always gives very good results. In this case, it does not give 0, but it does give a symbolic result equivalent to 0.



The same can be obtained in Matlab, in this case, using the sym command, which, by the way, changed its syntax very recently.



Also WolframAlpha has two answers for the same question, although in the end he opts only to show the exact value.



That is, the three programs coincide in giving something very close to 0, but not when the numerical answer is requested, and 0 or some expression equivalent to 0 when they are evaluated symbolically.

Anyway, if you check the code of the symbolic calculation programs you may be disappointed: to evaluate these types of formulas, they actually simply have a table of results where they can find the exact values ​​for a reduced input set. That is to say, in fact, until recently, almost no one applied very elaborate rules to solve those formulas.

Best regards.
Alvaro.

Yeah, did some more reading and I guess since pi is only carried out to 16 decimal places (floating), the conversion from radians to degrees (pi/180) is limited by the 16 decimal place value of pi.

What isn’t super clear is why it only happens with 270 degrees for cosine and 360 degrees for sine. Pi/180 is used to convert all input to angles.

Maybe at some point in my studies I learned why 270 degrees and 360 degrees are special, but I don’t remember now.

Wrote

Yeah, did some more reading and I guess since pi is only carried out to 16 decimal places (floating), the conversion from radians to degrees (pi/180) is limited by the 16 decimal place value of pi.

What isn’t super clear is why it only happens with 270 degrees for cosine and 360 degrees for sine. Pi/180 is used to convert all input to angles.

Maybe at some point in my studies I learned why 270 degrees and 360 degrees are special, but I don’t remember now.

Pi and more numbers are stored in computing machinery 40 decimals.
Not a single function exist in maths. They are approximated from the
4 basic arithmetic operations [+, -, *, /].
They are all normalized rational fraction P(n)/1+Q(n) on short range.
then like scaled. The coded native range is globally 21 floating point.
Error propagation brings down to around 18 floating point, by convention
15 digits are considered true to meet typical Abramowitz & Stegun.
Smath, Wolfram Alpha, Mathcad/PTC ... and else don't abide to the
convention of rounding smaller than 15 D to zero.
Mathcad 8, 2000, 2001i, 11 do round cos(270) = 0
In short, Smath does not calculate cos(270), trig and more exp, ln
are built-in in Windows. Smath and those more display the floating
point register, since when they broke the 15 D convention ?
Read more: Luke, Cody Junior, Hart et al.
round(cos((270),15)=0
Not built-in Windows from Smath menu ... Bessel, Airy ...
Have a good day ... Jean

This seems to be a good solution since only 270-deg with cosine and 360-deg with sine seem to be an issue.

Wrote

This seems to be a good solution since only
270-deg with cosine and 360-deg with sine seem to be an issue.

Add reality ...
Doing that is bug vs PTC Mathcad, Wolfram Alpha ...
The question is: why and since when CAS don't define result < 10^-15 = 0