How can I increase MaxProductWordLength to 256 ? in the function code? or generated code or test code?

How can I increase MaxProductWordLength to 256 ? in the function code? or generated code or test code? I came across the below error messages

Instrumented MEX file updated.### Generating Fixed Point MATLAB Code calc_fixpt using Proposed Types
### Generating Fixed Point MATLAB Design Wrapper calc_wrapper_fixpt
### Generating Mex file for ' calc_wrapper_fixpt '
??? MaxProductWordLength is 128 bits and a minimum word length of 148 bits is necessary so that this
product can be computed with no loss of precision. Increase MaxProductWordLength if you want the
product to grow to a larger word length. To constrain the result to a type with a smaller word length,
use colon-equals assignment, A(:) = B, or the CAST function.

Error in ==> calc_fixpt Line: 6257 Column: 12
Code generation failed: View Error Report

Answer 1

[Walter Roberson]

Well, you could increase it at the time you create the fi (fixedpoint object). I do not recall what the upper limit is; I seem to recall that there is a limit somewhere around 1023, but I cannot seem to find the appropriate message at the moment.

However, I have to ask whether you really want 148 bit calculations. Double precision is 53 bits of product, so you are asking for considerably more precision. The estimated distance from Earth to the edge of the observable universe is 4.4E26 meters; 148 bits is a range of about 1E44 units, so with 148 bits you could specify every position from Earth to the edge of the universe down to the attometre. That is rarely desirable.

[satish guruma]

the problem is that when I use input variable as 0.71, then the variable is represented as 0.7099991.. like this. in the HDL coder. So I thought that if I have more precision then that will fix. But As your recommends, I will reconsider this problem at the start point. might be it have to be 71 * 0.001.

[Walter Roberson]

You would need infinite precision to exactly represent 1/10 in binary.

When the system tells you it wants a precision like 148 bits, then that is because you have configured a policy of it being unacceptable to lose precision during multiplication. So if you had a 37 bit mantissa and you were to multiple two of those together, that would require 74 bits of mantissa to be sure of not losing any precision, and four such multiplications would need 148 bits to avoid losing precision.

The decimal equivalent would be starting with 3.14 as an approximation of pi, and then insisting that pi^2 -> 3.14 * 3.14 had to be 9.8596 exactly because you did not want to lose precision. However, when you use 3.14 in calculations, that covers all numbers between 3.135 (inclusive) and 3.145 (exclusive) so the square has to cover all of the range between 9.828225 and 9.891025, so insisting that the result had to be exactly 9.8596 would not really make sense from a scientific perspective.