FLoating point arithmetic problem - how to calculate/plot properly?

3 views (last 30 days)
I have an ODE that is solved for the time with different static parameters. I have a default setting for that from where I start. From this default setting, I change one of this static parameters at a time with 5% abbrevation from this default setting; I start the iteration at -50%:5:+50% so I "walk" over the default parameter value during the iteration. I want to calculate
ef=mean(diff(odesolution) and for the percentage abbrevation, I calculate:
diffslope=(ef*100)/defaultslope. Then I get as a result something around 100. When I then do the calculation diffslope -100, I dont get exactly 0 for the iterationstep solution where ef= defaultslope but something around 1e-14. When I syms the diffslope before and then substract 100, i can't plot it properly. Idiffslope is here already rounded to the 10th decimal place.
deltaslope1=((diffslope*100)/defaultslope) ;
sensvec=[-50:5:50]; %The percentage change I already know
figure(4);
plot(sensvec,deltaslope1, '-o')
xlabel('Percentage change of parameter from default')
ylabel('Percentage change of C1 slope from default')
title('Sensitivity')
xline(0)
xlim([-50 50])
I would prefer a solution where I get a clear result for deltaslope 1.

Answers (1)

Jan
Jan on 27 Apr 2021
Edited: Jan on 27 Apr 2021
This cannot work with floating point numbers. Remember that numbers stored in double format have a limited precision. Then claculations must include a rounding. You can only expect exact values, if the inputs and all intermediate values can be represented as binary values exactly. But this is a rare exception.
Welcome to the world of numerical maths. For more details: https://de.wikipedia.org/wiki/IEEE_754
  2 Comments
Marie P.
Marie P. on 27 Apr 2021
I guessed so but how I can cope with that? I mean, when the value that I expected to be zero isn't just because of that, I could theoretically expect also a numerical abbrevation of all the other values that I calculated from the "real" solution? I mean, it has already been rounded, so should I just then again round all the solutions to the 10th decimal digit?
Jan
Jan on 27 Apr 2021
Rounding is an option, but it does not fit all needs, e.g. if the value is greater than 1e17, rounding to decimal places is meansingless. Do not compare floating point values with 0, but apply a limit, e.g.: (x - y) < 10 * eps(max(abs(x, y)))
Yes, all values are concerned by the limited precision. Two common examples:
1e17 + 1 - 1e17 % == 0
1e17 - 1e17 + 1 % == 1
any(0:0.1:1) == 0.3 % false
any((0:0.1:1) - 0.3 < eps(0.3)) % true

Sign in to comment.

Products


Release

R2020a

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!