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