Machine precision in simulink
显示 更早的评论
Good morning everyone.
I am currently working on simulink model.
One of the equations is
"L = qf*(XL0+(XL1*alpha_quadrant))"
where "alpha_quadrant" is constantly zero. "XL0" and "qf" are both constants.
The result of the equation, when graphed, should be constantly -11.08, but as it can be seen in the picture the result keeps fluttering.
Is it because of the machine precision?
3 个评论
dpb
2021-7-14
Without Simulink in the picture, a product of two constants (presuming they are and do, in fact, remain constant) will indeed produce the same result to the final rounded bit.
Simulink, however, may do something behind the scenes in the model that mungs on the input terms that are those constants and thereby introduce some rounding which it would appear from the plot is what you're seeing.
However, would have to have the pertinent section of the model for anybody to be able to tell anything more definitive -- and, I don't have and have never seen a Simulink installation so I'm guessing here on what is possible given what I do understand about its operation.
MARCO LORENZI
2021-7-15
dpb
2021-7-15
"All that noise" is also in the 14th decimal place in the output. How can that make any real difference?
Just set
ylim([-10 -12])
on the plot so the tiny little jiggle isn't so amplified and you'd never have noticed it.
采纳的回答
Andy Bartlett
2021-7-14
To determine what is happening, a good approach is to log the key signals involved.
Then use MATLAB to investigate the logged values.
I suspect you'll find that either alpha_quadrant isn't always zero or qf is not constant or XL0 is not constant.
The differences in values from what you expect might be very small so you could use some techniques like the following.
format long g % will shows higher precision than short, but can still hide some differences
a = 0.05;
b = a + eps(a);
c = a + 2*eps(a);
v = [c,a,b] % the differences will not be visible in the command window
% converting to a string with 17 digits will be enough to see differences
mat2str(v,17)
% subtracting values is another way to make the differences visible in the
% command window
dv = diff(v)
max(dv)
min(dv)
The output of this code is:
v =
0.05 0.05 0.05
ans =
'[0.050000000000000017 0.050000000000000003 0.05000000000000001]'
dv =
-1.38777878078145e-17 6.93889390390723e-18
ans =
6.93889390390723e-18
ans =
-1.38777878078145e-17
Notice that differences in v are hidden even by format long g.
4 个评论
MARCO LORENZI
2021-7-15
Andy Bartlett
2021-7-15
Solvers are designed to give "accurate enough" answers in acceptable amounts of time. Due to the limits of finite precision math, the goal is not to get the ideal math answer, just an answer "close enough" to satisfy engineering requirements. Some Simulink solvers provide the ability to specify an absolute and relative tolerance. If the goal is to reduce the fluttering of signals that in ideal precision should be constant, then you could try to make the tolerances tigher (smaller). This will likely make the simulation time longer, but increase accuracy.
Before tightening the tolerances and slowing down your simulations, you might want to look at the observed fluttering with regard to your higher level engineering requirements. Determine how much, if at all, the fluttering prevents you from achieving your higher level engineering goals.
MARCO LORENZI
2021-7-15
That really isn't what Andy said -- he said, in fact, the obverse -- if you want smaller jiggles on the near constant, you have to actually add more precision, not reduce it.
You can loosen tolerances to get fewer significant digits although if you go too far, solutions may,in fact, diverge from the real solution completely.
Before that point, while your simulation may run faster and will have lower absolute accuracy, it won't be by effectively "zero-ing out" more digits of precsion; the simulation will still be calculated in double precision floating point and so will have the full mantissa; what you'll get will be even more jiggles in your constant up to that level of accuracy you've specified for the solver.
There simply is no such thing as you're thinking of it as being N digits of numeric precision and everything past that identically zero -- in fact, that is in essence infinite precision because you've set a requirement on every digit from the first to as many as you want to name.
You could, I guess, insert an s-function as the output of every block that rounds the result before passing it to the next, but it's futile and pointless to do so...just use the simulation results you get. As noted above, if you were to change the scale on the plot to something realistic about the magnitude of the value itself, you would not even see the jitter and would not have even recognized it as being there.
It just doesn't matter in a practical sense.
更多回答（0 个）
类别
在 帮助中心 和 File Exchange 中查找有关 General Applications 的更多信息
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!
Translated by 
