> 99.99% of the code snippets in that realm work great with 64b floating point, without the author having invested any thought at all into "numerical analysis"

> 99.99% of the code snippets in that realm work great with 64b floating point, without the author having invested any thought at all into "numerical analysis" In the accident that they "work great" (really, great?) it's only because: - The code depends on properties of IEEE FP which were designed exactly so that it's harder for a casual user to shoot himself in the foot -- ant these properties were intentionally designed for IEEE FP by the people who DID invest a lot in "numerical analysis" and the practical consequences of potential bad decisions. - The code depends on libraries that were designed with much more effort than the author of the above statement can imagine. In short, yes, we do need all features of IEEE FP. And to produce anything non-trivial one should indeed learn more about all that, and care. > Summary: use SSE2 or SSE, and if you can't, configure the FP CSR to use 64b intermediates and avoid 32b floats. Even the latter solution works passably in practice, as long as everybody is aware of it. That was, and I guess it hasn't changed, the default with Microsoft's compilers on Windows for decades already, and probably sensible default for non-Microsoft scenarios, especially needed for the "consistency" across the compilers, which matches the title of the article. Oh, and make sure that the compiler doesn't do any optimization that produces unstable results. That's about the "production" default. However, I still believe that during the development of anything non-trivial the evaluation of the results using different numbers of bits is worth doing.