0
\$\begingroup\$

I was reading a chapter of my book (I am not putting it as reference since it is not in english) about the quantization noise problem in digital filters. Specifically, it writes about a filter that performs multiplication operations:

"If the input, the output and the multiplicative coefficients of the filter are numbers that can be represented with n bits, maintaining this accuracy in the calculations requires greater precision since, typically, multiplying two numbers of n bits produces a number that can be represented with 2n bits. The need to round the intermediate results therefore produces an error called truncation noise".

To understand exactly what happens I would need a practical example. For example I don't understand if the truncation refers to integers (for example 180 becomes 200) or only for decimal numbers (for example 180.5 becomes 180).

Take for example the numbers 200 and 4, each expressed with 4 bits, that is with 16 levels (therefore 200 will have a resolution of 200/16 = 12.5, and 4 will have a resolution of 4/16 = 0.25). Multiplying them you get 800. Representing it with 4 bits you get a resolution of 800/16 = 50. Is this what is meant by truncation? What is the relationship between the accuracy of the result and that of the operands?

\$\endgroup\$
2
\$\begingroup\$

It means if you multiply say two 16-bit numbers together, the result is 32 bits. Example: 65535x65535 = 4294836225.

If you must store the 32 bit result into 16 bits, you need to keep 16 bits and throw away 16 bits, therefore the result is truncated to 16 bits, so the value is not exact and there is error from the truncation.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ So will I cut the 16 LSB? \$\endgroup\$ – Kinka-Byo Apr 24 at 12:58
  • \$\begingroup\$ Yes, obviously. In same way like when you round normal numbers like 3.14159265 to integer, you keep the 3 and cut away the .14159265. \$\endgroup\$ – Justme Apr 24 at 13:22
  • \$\begingroup\$ Okay, thank you very much. For instance, let's suppose to execute 8 (1000) × 5 (101) with only 5 bits for the result. We get 40 (101000), which with only 5 bits become 20 (10100). Is it normal that a truncation or 1 bit determines a so big error? \$\endgroup\$ – Kinka-Byo Apr 24 at 17:21
  • \$\begingroup\$ I have this doubt because it is a very big error, so a truncation 16 -> 8 would determine a completely wrong result \$\endgroup\$ – Kinka-Byo Apr 24 at 17:33
  • 1
    \$\begingroup\$ The point is not that the value gets halved. It still has magnitude of 40 in 6-bit notation. The point is that when you represent it with 5 bits you lost one bit of resolution, which means the resolution is now 2. You can't represent odd numbers any more. So the numbers you chose are not a good example. 5(101)x7(111)=35(100011) is better. If you chop one bit off, it truncates to 34. Virtually those bits can be thought to exist but are not stored physically anywhere so they are zeroes. \$\endgroup\$ – Justme Apr 24 at 17:44
0
\$\begingroup\$

It is integer truncation, mainly from divisions as unless you build in rounding functions 80.9 becomes 80,

say you have a muliplication that will not have an even result, e.g. 81x49 = 3969, now if stored in a 16 bit value would be fine, but if you now need to output that on an 8 bit DAC, you have to scale it down, e.g. divide by 256 if you where not exactly sure of the output size, meaning you end up with a result of 15, when rounded would be 16, and in both cases you have thrown away a lot of information,

Division is your enemy here, as unless you save the modulo and use it to round your usually throwing away some amount of the precision of the original value. e.g. your running it through multiple filters, the best result you could hope for would be to leave a single division to the end for the least information lost due to truncation.

| improve this answer | |
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.