That statement that you refer to regarding the instructions for transcendental functions in 80 bits doubles is the result of the way the hardware and the microc

That statement that you refer to regarding the instructions for transcendental functions in 80 bits doubles is the result of the way the hardware and the microcode for these functions are implemented. Internally, out of 80 bits, 64 bits are available for mantissa and the steps for calculating the result accumulate the error, and then the last two bits in these transcendental functions are "noisy" which was still very good for its time. And it was documented. But that's still only for the "convenient" input range for the implemented algorithm. In practice, the programmers sometimes want to pass the values from the less convenient input range, and then it got much worse when the library functions in high level languages have expected too much from the implementation in the processor: https://randomascii.wordpress.com/2014/10/09/intel-underestimates-error-bounds-by-1-3-quintillion/ https://randomascii.wordpress.com/2014/10/09/intel-underesti... The resulting problem in the high level implementation described described was blind belief in the wrong (in not correctly stating the input range) documentation by some that then implemented the C library functions for some environments, only a few years ago: The Intel's documentation was "buggy. By claiming near-perfect accuracy across a huge domain and then only providing it in a tiny domain Intel has misled developers and caused them to make poor decisions." And it was fixed in 2014: https://software.intel.com/blogs/2014/10/09/fsin-documentation-improvements-in-the-intel-64-and-ia-32-architectures-software https://software.intel.com/blogs/2014/10/09/fsin-documentati...