Functions like COS() or SIN() are computed with a polynomial approximation called “limited development”. You have first a quotient PI()/2 which is itself approximate. You then cumulate two approximations. If you’re versed in mathematics, you can evaluate the final error resulting from inexact argument, method error (truncated polynomial development) and computation itself (every operation is inexact and mapped to the “nearest” representable value).
Never trust floating-point computation, it will never give an exact result. If the algorithm is long enough (which is not the case for COS() and SIN()), the result may be really far away from what math tells.
In your case 10-16 is fairly close to zero. The main point is how this magnitude compares to other quantities it may be added to. If their orders of magnitude are “sufficiently” different, the tiny “false zero” does not matter. What is important is the usage you put to this “false zero”.
LO by itself cannot “correct” the small quantity to zero because it can’t assert that the argument is strictly equal to pi/2 because equality has no meaning with floating-point.
To show the community your question has been answered, click the ✓ next to the correct answer, and “upvote” by clicking on the ^ arrow of any helpful answers. These are the mechanisms for communicating the quality of the Q&A on this site. Thanks!
In case you need clarification, edit your question (not an answer which is reserved for solutions) or comment the relevant answer.
