Formally, math library functions should treat their inputs as representing exact real-number values, not approximate ranges. All good math library implementati

Formally, math library functions should treat their inputs as representing exact real-number values, not approximate ranges. All good math library implementations hold themselves to a higher standard than a naive backwards error bound you refer to. “Infinite-pi” range reduction providing good relative accuracy for all inputs is used in the software implementations of trig functions from Intel, NVIDIA, Apple, IBM, HP and Sun, to name just a few companies, as well as most widely used third-party math libraries, so it’s not really accurate to say that very few implementations bother (though that would have been true 20 years ago). This can be done with minimal performance impact for “normal” arguments, and not doing so today is frankly pretty sloppy. Implementing these operations via a naked FSIN or FCOS instruction is especially horrific; even worse than using only ~67 bits of pi, those instructions simply do not support arguments with an exponent larger than 63, and on some architectures will simply return the input unchanged (i.e. the result of sin(HUGE) will not even lie in [-1,1], which breaks all sorts of invariants one would like to hold. For instance, asin(sin(x)) may then be NaN for finite x, and sin^2(x) + cos^2(x) won’t be even close to 1).