> Don't just sprinkle these optimizations throughout your code without understanding the accuracy requirements of your program. There is a relatively straightf

> Don't just sprinkle these optimizations throughout your code without understanding the accuracy requirements of your program. There is a relatively straightforward way to think about this. Either your program depends on fully accurate error analysis (e.g. for reproducibility), or not. If yes, you would not even think of enabling fast-math, because that's implementation-defined behaviour. If no, any mathematically valid substitution will do, unless it causes some kind of unlikely numerical instability. In the case of evaluating a/x as t=1/x;a * t, it is possible to analyze the optimization exactly: without overflows, the relative error of a * (1/x) will be at most 2u/(1-u), while relative error of a/x will be at most u. Thus this substitution is absolutely fine, there's no need to be scared of it. Mathematically sensible transformations generally produce sensible results. It is exceedingly uncommon for someone to need a perfectly rounded result.