On 26/12/11 01:58, Vincent Lefevre wrote:
On 2011-12-24 12:02:24 +0100, David Brown wrote:
And (regarding other examples in your posts) if floating-point code
depends on things like the order of calculations, it is also wrong -
thus "-ffast-math" will not affect the correctness of the program,
but will sometimes greatly improve the speed.
Whether you like it or not, a floating-point result does depend on the
order of calculations in general. How would you write code to compute
the mathematical expression a + b - c where you know that you have the
property 1/2<= a/c<= 2 on the inputs? Or code to compute a*a - b*b
where a and b are close to each other? With the IEEE 754 rules, one
can use formulas that give very accurate results, but if the compiler
is allowed to rewrite the code (without control from the developer who
wrote the code), the results may no longer be accurate (and may even
be quite wrong).
If it matters that "a + b - c" be calculated "(a + b) - c" or "a + (b -
c)", then use brackets. That what you show the compiler and people
reading the code what's going on. 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. And it's not uncommon that you have
to use brackets like this to ensure everything works out correctly.
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. 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.
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 think I'm alone in wishing that more programmers used stricter
coding practices
On the contrary, we are very strict on coding practices in order to
get accurate results.
I realise that, but I don't think you count as "most programmers" in
this sense - as far as I can tell, you have rather specialised needs.
You have different requirements than mine, but at least as strict.
