In article , Michel Hack writes: |>
|> Here, the point is: how about the right question?
Agreed.
|> The proper function to use in most engineering (cycle simulation, |> graphics etc.) calculations is sinpi(), not sin(). In other words, |> only use rational parts of a cycle, so the circle closes exactly. |> It is only when doing mathematical analysis that sin(radians) is |> sensible. The trouble is historical -- sinpi() may be too new.
Grrk. No. Yes, it is often an appropriate function, but it is NOT the relevant one for most engineering - only the most simplistic forms of it. As soon as you have to do calculations as basic as the forces in a particular direction due to a rotating, unbalanced object, using radians is generally the right approach.
And it isn't a new function. After all, the official standard for measuring angles is the grad :-)
|> As to why sin() should return the right answer, which in this context |> means interpreting input values as exact (in the actual format used, |> e.g. double, and not a pre-conversion value like 1e300 (unless DFP is |> being used, of course)), it is for reproducibility. A vendor of a |> math library (or a machine instruction) wants to be able to improve |> the implementation without changing the results. The only sensible |> way to do this is to produce the correctly-rounded result, though |> the option to limit (and document) the range, and out-of-range |> behaviour, remains open.
That is a fantasy. While it is possible for trivial calculations like sin(), bitwise reproducibility forces both serialisation and effectively no change to the implementation, ever again. Even simple calculations like linear equations, eigenvalues and fast Fourier transforms are sensitive to the exact operations used.
On the contrary, the only sensible approach is to pursue reasonable accuracy, which gives reproducibility to within the numerical analysis of the problem.
Regards, Nick Maclaren.