Quote:
Quote:
If a compiler is dumb, you'll get c = .18, d = .18 * 11 = 1.98.
If the compiler is smart, it will see that d = (b/a)*a = d = 2.
And if the compiler is strict, it will still reply with 1.98 because that's what the programmer asked - this makes floating point calculation optimizations nearly impossible (and I've turned this strictness off).
Moving code around leads to different "smartness" of the compiler, hence to (slightly) different results.
Ah ... clear now. Thanks for exemplifying this. So, if I understood you right, post organizing your code, there's a variance in 'obscurity' to the compiler for such floating point operations. Nothing relevant to the output of the filter quality.
Yes. At least that's what I think it is. I compared the audio of the latest build (before the quality improvement) against that of 029 and I saw some difference in the last bit, sometimes even the last 2-3 bits, in some presets (some others were 100% identical). Since I didn't change anything in what the code should do, and real bugs would cause *much* bigger differences, I figured it has to be a rounding issue.
By the way, if I turn *all* the optimizations off, the difference can sometimes even amount to over 5% of the total signal! Which is quite insane... (And runs at about 1/10th of the speed, so it's completely unusable).