ISSUE: floating-point-inaccuracy of low frequency filters with low
frequency signals in pd vanilla
The patch "Test_HP3_butterworth_@_20_Hz.pd" is part of the Live
Electronic of K.H.Stockhausens piece Mikrophonie I.
My colleague David P. told me, that there occur hearable noise,
distortion, oscillations and rustling during perfoming this piece.
The test-patch is a 0.1 Hz oscillator sourcing a highpass filter
3.order with butterworth characteristic at 20 Hz.
Try this patch with pd-0.52-1-msw-i386 and amd64 aka 32-bit and 64-bit
and older pd versions.
The 32 bit version has 20 dB less noise than the 64 bit version (and
no oscillations).
Double precision filters of iemlib ("hp3_butt_dp~.pd") have less noise
than single precision filters.
IOhannes z. and Chrostof R. figured out, it depends on compiler
options -ffast-math and / or -fassociative-math.
Some screenshots are added.
have fun
Thomas Musil
Generally, I can reproduce the output, including the funny noises on Pd-0.52.1 64-bit.
IOhannes z. and Chrostof R. figured out, it depends on compiler options -ffast-math and / or -fassociative-math.
That's only half the story. Generally, one shouldn't expect floating point computations to yield the exact same result with different compilers/machines. The rounding errors themselves are very small, but they can accumulate over long periods of time or get amplified by recursive algorithms.
However, in this case, the actual problem is really the implementation of [biquad~]. It uses direct form 2 - which requires fewer delay units, but is less numerically stable. (https://en.wikipedia.org/wiki/Digital_biquad_filter)
I've made an alternative implementation [biquad2~] that uses direct form
- It shows significantly less noise than the [biquad~] examples. See
attachments.
Christof
On 10.02.2022 14:01, musil@iem.at wrote:
ISSUE: floating-point-inaccuracy of low frequency filters with low frequency signals in pd vanilla
The patch "Test_HP3_butterworth_@_20_Hz.pd" is part of the Live Electronic of K.H.Stockhausens piece Mikrophonie I. My colleague David P. told me, that there occur hearable noise, distortion, oscillations and rustling during perfoming this piece.
The test-patch is a 0.1 Hz oscillator sourcing a highpass filter 3.order with butterworth characteristic at 20 Hz.
Try this patch with pd-0.52-1-msw-i386 and amd64 aka 32-bit and 64-bit and older pd versions. The 32 bit version has 20 dB less noise than the 64 bit version (and no oscillations).
Double precision filters of iemlib ("hp3_butt_dp~.pd") have less noise than single precision filters.
IOhannes z. and Chrostof R. figured out, it depends on compiler options -ffast-math and / or -fassociative-math.
Some screenshots are added.
have fun
Thomas Musil
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Zitat von Christof Ressi info@christofressi.com:
That's only half the story. Generally, one shouldn't expect floating
point computations to yield the exact same result with different
compilers/machines. The rounding errors themselves are very small,
but they can accumulate over long periods of time or get amplified
by recursive algorithms. I've made an alternative implementation [biquad2~] that uses direct
form 1. It shows significantly less noise than the [biquad~]
examples. See attachments.
That's right what you wrote.
However, what worries me is that if I run a Pd vanilla patch on
different Pd versions (i386 or amd64) with the same floating point
precision, I expect the same results.
e.g. the test patch running on Pd-0.52-1-xxx-i386 produces -60dB low
frequency spikes, the identical patch running on Pd-0.52-1-xxx-amd64
produces -34dB high frequency bursts. And that's a realistic simple
situation, a microphone signal feeds a 3rd order high pass filter.
Thomas Musil
However, what worries me is that if I run a Pd vanilla patch on different Pd versions (i386 or amd64) with the same floating point precision, I expect the same results.
Generally, you can't really expect that. Even without -ffast-math, different CPU architectures or instruction sets will give slightly different results (unless you jump through various hoops).
Here's an interesting article by a game developer: https://gafferongames.com/post/floating_point_determinism/
Usually, these errors are very small, but with (suboptimal) recursive algorithms they can get amplified significantly. Your patch is a very striking demonstration of the problems with the direct 2 form of the biquad filter :-)
Christof
On 11.02.2022 23:11, musil@iem.at wrote:
Zitat von Christof Ressi info@christofressi.com:
That's only half the story. Generally, one shouldn't expect floating point computations to yield the exact same result with different compilers/machines. The rounding errors themselves are very small, but they can accumulate over long periods of time or get amplified by recursive algorithms. I've made an alternative implementation [biquad2~] that uses direct form 1. It shows significantly less noise than the [biquad~] examples. See attachments.
That's right what you wrote. However, what worries me is that if I run a Pd vanilla patch on different Pd versions (i386 or amd64) with the same floating point precision, I expect the same results.
e.g. the test patch running on Pd-0.52-1-xxx-i386 produces -60dB low frequency spikes, the identical patch running on Pd-0.52-1-xxx-amd64 produces -34dB high frequency bursts. And that's a realistic simple situation, a microphone signal feeds a 3rd order high pass filter.
Thomas Musil
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Just to ad tothe confusion ... I'm running tests ("reality check") to see of Pd runs musical pieces the same way on diffrent machines. I found that AMD64 Pd on linux and on MacOS (both 64-bit Intel CPUs) gave slightly different results, off by less thatn a part in a million (10^-6 error). But.. the MacOS test gave the identical same result as a Raspberry Pi, which is in 32 bits and has an ARM processor.
I _think_ linux and MACOS are setting different rounding modes in the processor, but haven't takent the time to try to figure it out.
cheers Miller
On Fri, Feb 11, 2022 at 11:25:26PM +0100, Christof Ressi wrote:
However, what worries me is that if I run a Pd vanilla patch on different Pd versions (i386 or amd64) with the same floating point precision, I expect the same results.
Generally, you can't really expect that. Even without -ffast-math, different CPU architectures or instruction sets will give slightly different results (unless you jump through various hoops).
Here's an interesting article by a game developer: https://urldefense.proofpoint.com/v2/url?u=https-3A__gafferongames.com_post_...
Usually, these errors are very small, but with (suboptimal) recursive algorithms they can get amplified significantly. Your patch is a very striking demonstration of the problems with the direct 2 form of the biquad filter :-)
Christof
On 11.02.2022 23:11, musil@iem.at wrote:
Zitat von Christof Ressi info@christofressi.com:
That's only half the story. Generally, one shouldn't expect floating point computations to yield the exact same result with different compilers/machines. The rounding errors themselves are very small, but they can accumulate over long periods of time or get amplified by recursive algorithms. I've made an alternative implementation [biquad2~] that uses direct form 1. It shows significantly less noise than the [biquad~] examples. See attachments.
That's right what you wrote. However, what worries me is that if I run a Pd vanilla patch on different Pd versions (i386 or amd64) with the same floating point precision, I expect the same results.
e.g. the test patch running on Pd-0.52-1-xxx-i386 produces -60dB low frequency spikes, the identical patch running on Pd-0.52-1-xxx-amd64 produces -34dB high frequency bursts. And that's a realistic simple situation, a microphone signal feeds a 3rd order high pass filter.
Thomas Musil
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
-
Christof Ressi -
Miller Puckette -
musil＠iem.at