Double Precision in Green Math

[Rocko]

hi,

I believe that IIR EQ filters need double precision float values, single precision not being enough, which might cause stability issues.

Looking for a method to use 'double precision float' in green. Does it exist? Can I use RUBY instead?

I've been reading through this link but didn't really find an answer to my question.
http://www.dsprobotics.com/support/viewtopic.php?f=2&t=2810&p=14906&hilit=double+precision#p14906

Is the answer to simply use STRING for higher precision??

[tulamide]

hi,

I believe that IIR EQ filters need double precision float values, single precision not being enough, which might cause stability issues.

Looking for a method to use 'double precision float' in green. Does it exist? Can I use RUBY instead?

I've been reading through this link but didn't really find an answer to my question.
http://www.dsprobotics.com/support/viewtopic.php?f=2&t=2810&p=14906&hilit=double+precision#p14906

Is the answer to simply use STRING for higher precision??

I know this will sound strange, but you can use whatever you like. For a processor, all that counts are bits, and nothing else. It's us humans who needed constructs like String, Int, Float, Hex etc. to differentiate the bit formations.

Say, you have a task where you need to work with data between -0.00127 and +0.00127. You need the data to be precise, but you only can use a width of 8 bits. The solution would be a signed char. A char uses 8 bits, and signed means that either the lsb or the msb (depending on system and programming language used) is used to indicate negative (1) and positive (0)

The remaining 7 bits will just be interpreted as factors of 2^x, as always. You now can represent a number between -127 and +127, which you can work with. Only when presenting it to humans you convert it to a string prefixing "0.00"

Working in green means working without sample precision. Whenever that is given, you can as well use Ruby. In Ruby you have a lot of possibilities to work with different number formats.

The real issue is, that at some point you need to feed the number back into green. At that point it will be converted back to (or at least interpreted as) single precision float. As long as this doesn't change, you won't be able to work with any other precision in green.

[Rocko]

Hi,

Thanks for the answer, but I'm missing the point here.

assuming that an IIR filter relies on biquads and that the biquads need to be in double-precision accuracy, do you suggest that one can not use 'green math' to calculate it? Or do you mean that it is calculated as double precision, but only viewed to us humans as single precision?

[martinvicanek]

Why do you think you need double precision?

[Rocko]

Hi,

Well, I might have got it all wrong, but when I save the coefficients of a bi-quad IIR filter with FS/SM I see 'just' 8 digits 'after the decimal point'.

I had noticed that books and literature show 16 digits 'after the decimal point'. Like so:
http://www.earlevel.com/main/2013/10/13/biquad-calculator-v2/

[martinvicanek]

In the Earlevel biquad calcuator, try change Fc from 10000 Hz to 10001 Hz. Observe which digits of the biquad coefficients change.
I have yet to see a situation in audio processing where you REALLY need double precision. Biquads as such are pretty much stable with single precision coefficients, even at extreme Q values. However, note that there are many, many different implementations of a biquad fiter with a given transfer function. Direct forms are most common, but not always the best choice. Indeed, single precision direct forms will cease to work for subsonic frequencies. There are other biquad implementations which do not have this probem, e.g. the SVF with zero delay feedback.

[tulamide]

Hi,

Thanks for the answer, but I'm missing the point here.

assuming that an IIR filter relies on biquads and that the biquads need to be in double-precision accuracy, do you suggest that one can not use 'green math' to calculate it? Or do you mean that it is calculated as double precision, but only viewed to us humans as single precision?

For all things technical to dsp, listen to Martin. He knows his stuff better than anyone else currently active on these forums.

Regarding green and Ruby, I wanted to show two things at once.
1) You can work with any format you like within Ruby. Green however is fixed to single precision. The only way to work with double precision throughout Flowstone is using stream and dsp code that directly works with those dp values.
2) You don't always need large bit tiers. It depends on the range of values rather than the values themselves. Imagine you need to express a tiny difference and therefore need the values 0.0000000000000001 and 0.0000000000000000. A case for double precision? Not neccesarily. The difference is just one digit, that can be 0 or 1. 0 or 1 is expressed with just one bit. So you could work with a simple integer in green (you would in fact just work with one bit of that int), holding 0 or 1. Only in the dsp module you would then convert this number to 0.0000000000000001 (or 0).

[MyCo]

In the Earlevel biquad calcuator, try change Fc from 10000 Hz to 10001 Hz. Observe which digits of the biquad coefficients change.
I have yet to see a situation in audio processing where you REALLY need double precision. Biquads as such are pretty much stable with single precision coefficients, even at extreme Q values. However, note that there are many, many different implementations of a biquad fiter with a given transfer function. Direct forms are most common, but not always the best choice. Indeed, single precision direct forms will cease to work for subsonic frequencies. There are other biquad implementations which do not have this probem, e.g. the SVF with zero delay feedback.

There was somewhere a thread with a double precission biquad, in that case you could really hear the difference because of the biquad form that was used. I can't find it anymore, though.

[Rocko]

Hi,

For all things technical to dsp, listen to Martin. He knows his stuff better than anyone else currently active on these forums.

sure, I had taken some of (corretion:Martin and Myco's) advice in the past always top level answers.
In fact I had designed my own version of EQ (normal second order IIR filters) and noticed that the resolution is enough with FS float, which raised the question "why does literature always show so many more 'digits after the decimal point'? "
That is why I'm raising the question in the forum...

so, let me reverse the question. FS/SM is float representation is good enough, why then does the literature use so many digits after the decimal point then?

In theory (not IIR coefficient), a number between 9.9999999 and -9.9999999 can be represented in binary by 27 bits, correct?

Isn't the calculation as so (N=number of bits):
N= Log(2)[2*99999999] ==> 27

This should be enough for the task of filtering.

[MyCo]

Floating point binary representations aren't linear. They are exponential with sub dividers. Basically the steps between two adjacent values (that can be represented) are smaller the smaller the value are.

In case of displaying, FS just doesn't show all digits because they mostly don't matter and would disrupt the user too much. But you can display them in fully glory like that: