[music-dsp] Re: floating point running sum optimization

[Richard Dobson]

Evaluation of sub-expressions is a separate issue from precedence. 
Expressions at the same precedence level are evaluated left to right 
(mostly; = is evaluated right to left, for example ), but the 
expressions themselves (if in the form of sub-expressions) may be 
evaluated in different orders by the compiler.

  a + b - c is therfore mandated to be evaluated as (a+b) - c

In what order a, b and c are each evaluated ~as expressions~ is another 
matter. It is well if c does not have side-effects impacting on b or a, 
or vice versa, etc.

I think that it is always a good idea to use explicit brackets anyway, 
as part of self-documentation. Brackets cost nothing.

In the case of  a + b - b I would suspect the optimiser first of all 
(and especially M$s one!). Possibly, some "obvious" optimisations are 
done even in debug builds?


Richard Dobson



Ross Bencina wrote:

...
> 
> I kind of agree with your "letter of the spec" comment, however I think most
> people doing numerical stuff in C (or C++) expect a high degree of standards
> conformance in this area. If it's not needed there is usually
> a --fast-floating-point flag. Unfortunatly my ANSI C standard is boxed away,
> but I would be surprised if there isn't a clause which says something like
> "evaluation order is non-specified but the results should be the same as if
> the order was as written (left to right as Laurent said). Compiler text
> books usually make it pretty clear that reordering optimisations on floating
> point expressions is a dangerous business and that  (a + b) - c is usually
> not equivalent to a + (b - c). Anyhow, I'll shut up now, no point defending
> the gospel without a bible in hand.
> 
...