> The trigonometric functions with arguments measured in cycles are more accurate and faster to compute.
Please expand on this. Surely if that were the case, numerical implementations would first convert a radian input to cycles before doing whatever polynomial/rational approximation they like, but I've never seen one like that.
> Because Pi is needed so much more rarely, it is simpler to just have a constant Pi_2 to be used in most cases and for the rare case of computing a circumference from the diameter to use Pi_2*D/2,
Well of course, that's why you have (in C) M_PI, M_PI2, and so on (and in some dialects M_2PI).
> Surely if that were the case, numerical implementations would first convert a radian input to cycles before doing whatever polynomial/rational approximation they like, but I've never seen one like that.
Then you have not examined the complete implementation of the function.
The polynomial/rational approximation mentioned by you is valid only for a small range of the possible input arguments.
Because of this, the implementation of any exponential/logarithmic/trigonometric function starts by an argument range reduction, which produces a value inside the range of validity of the approximating expression, by exploiting some properties of the function that must be computed.
In the case of trigonometric functions, the argument must be reduced first to a value smaller than a cycle, which is equivalent to a conversion from radians to cycles and then back to radians. This reduction, and the rounding errors associated with it, is avoided when the function uses arguments already expressed in cycles, so that the reduction is done exactly by just taking the fractional part of the argument.
Then the symmetry properties of the specific trigonometric function are used to further reduce the range of the argument to one fourth or one eighth of a cycle. When the argument had been expressed in cycles this is also an exact operation, otherwise it can also introduce rounding errors, because adding or subtracting Pi or its submultiples cannot be done exactly.
We start of with a range reduction to [0, pi/4] (presumably this would be [0, 1/8] in cycles), and then the polynomial happens.
If cycles really were that better, why isn't this implemented as starting with a conversion to cycles, then removal of the interval part, and then a division by 8, followed by whatever the appropriate polynomial/rational function is?
> adding or subtracting Pi or its submultiples cannot be done exactly.
I was also assuming that we've been talking about floating point this whole time.
Please expand on this. Surely if that were the case, numerical implementations would first convert a radian input to cycles before doing whatever polynomial/rational approximation they like, but I've never seen one like that.
> Because Pi is needed so much more rarely, it is simpler to just have a constant Pi_2 to be used in most cases and for the rare case of computing a circumference from the diameter to use Pi_2*D/2,
Well of course, that's why you have (in C) M_PI, M_PI2, and so on (and in some dialects M_2PI).