On Fri, 8 Oct 2021 19:44:48 +0200
Ichthyostega <p...@ichthyostega.de> wrote:
This afternoon, I systematically repeated the testsuite execution on a
Laptop, which significantly differs in performance to my Desktop PC.
Another irritating observation however is, that I get a *sound
difference* on the calculated WAV file. The difference is extremely
small, peak Δ -121.511dB(RMS). I can not hear it, it becomes only
apparent when applying an extreme amplification on the residual WAV. It
is basically slightly coloured white noise, with an faint trace of the
actual sound.
Am 11.10.21 um 20:09 schrieb Kristian Amlie:
https://en.wikipedia.org/wiki/IEEE_754#Reproducibility seems to indicate that
some variations are allowed, especially in the stored binary form. Given how
small the difference is, I wonder whether this is on the brink of floating
point precision, and that *numerically* they are still "essentially" zero.
Yeah, that's my suspicion too.
Unfortunately, the standard allows some leeway, which (If I recall correct)
was pushed in basically by Intel, because they wanted to optimise or improve
their FPU-Units. Some FPU-Units have an additional bit, which allows to reduce
the error, but unfortunately this is unstable under optimisation, and this
brings in an random element. In theory, floating-point operations could be
imprecise, yet totally deterministic. But hardware vendors wanted to be
especially clever, and now we have to fact indeterminism in numerics.
One thing we could do to remedy that is simply to convert it back to signed
16-bit integer format. This isn't a good format for processing, but it's good
for a final render, and should get rid of these extremely tiny and
insignificant differences.
Yes, this is an obvious idea -- however, it does not work in practice.
And this is due to the aforementioned randomness in the last bit.
You can't get rid of randomness just by quantisation (rounding into
a grid). You will still get a random flip either to the one side, or
the other side. Obviously, you'll see less of those random flips
after the rounding, but you can't get rid of them. And, what's worse,
by rounding, you increase the error; since rounding means to throw
away at least one bit, when the flip happens on your rounded last
place, it will always be larger than the random noise was on the
original, un-rounded raw value.
So what you typically do is just to introduce some kind of epsilon
or tolerance level into the comparison.
In our case, where we're calculating a RMS in decibel below the
RMS of the actual test wave, this would just mean that we'll have
to find out some lower bar, and don't raise an alarm if the
computed difference has an RMS below that tolerance level.
-- Hermann
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
