On 2011-12-26 12:37:27 +0100, David Brown wrote: > If it matters that "a + b - c" be calculated "(a + b) - c" or "a + (b - c)", > then use brackets. but brackets shouldn't change anything with -fassociative-math. In C, brackets are purely syntactic, i.e. a + b - c is equivalent to (a + b) - c. > That what you show the compiler and people reading the code what's > going on. Not in C. > In my type of programming, if you need to be sure of precise > calculations, you always use integer arithmetic - it's clear and > well-defined, with no scope for inaccuracies, rounding errors, etc. This is the contrary. IEEE 754 completely specifies the floating-point arithmetic, even more than how integer arithmetic is specified by C: in C, an overflow on signed integers gives undefined behavior, while IEEE 754 specifies all the floating-point exceptions, and everything is well defined. BTW, concerning integer arithmetic vs floating-point arithmetic, there are good reasons why the plane industry is switching from integer arithmetic to floating-point arithmetic... Except for specific problems, integer arithmetic for computations on real numbers is the past. > And it's not uncommon that you have to use brackets like this to > ensure everything works out correctly. If you assume that this will make a difference, that's a bad practice. > In your example, I don't see how a difference in the ordering of > calculations will make a difference to the result of more than an > LSB or two unless there were wildly differing magnitudes involved. The difference is precisely when differing magnitudes are involved. This happens in practice. Very often. > And that's something to avoid - you are never going to get accurate > results by adding or subtracting values of wildly different > magnitudes in floating point. You may be able to get consistent, > precise, well-defined, portable results - but you will not get > correct or meaningful results. You're wrong. When the operations are done in a well-specified order, one can get very accurate results (one can even emulate precisions higher than the one of the floating-point system), and one can *prove* these results. I really suggest that you read our "Handbook of Floating-Point Arithmetic". > My point is that you have to take that kind of effect into account > when writing the algorithm and the code. To my mind, it doesn't make > sense to add a distance in kilometres to a distance in nanometres > and expect sensible results. If you have a situation where what is > called for (maybe you work are CERN), then you are probably better > off storing all your distances as int64_t femometer units. I don't work at CERN and personally don't work with physical quantities. But for instance, if you want to calculate a derivative numerically (something that happens very often in scientific code, either directly or indirectly), you will have cancellations and the magnitudes greatly differ. Magnitudes also differ when one wants to emulate a greater precision as said above (something quite specific, but necessary when one wants to implement some mathematical function accurately). -- Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
