why does matlab invent decimal numbers?

2 views (last 30 days)
long = 2.305800000000000e+03;
short= 8.694000000000000e+02;
prof=3.175200000000000e+03
prof = 3.1752e+03
dail=long+short
dail = 3.1752e+03
dail-prof
ans = 4.5475e-13
%{
In my count: daily=2305.8+869.4=3175.2
dail-prof=0 but matlab write dail-prof=4.5475e-13
why does matlab add infinitesimals of decimals to me?
i see https://it.mathworks.com/help/matlab/matlab_prog/floating-point-numbers.html#f2-98690
but I didn't find it useful
%}
  2 Comments
Star Strider
Star Strider on 23 Jun 2024
Edited: Star Strider on 23 Jun 2024
We covered this in your other post: How avoid exponential notation in compose. I even provided you with a line to the appropriate documentation section, that you wrote that you referenced and read.
EDIT — (23 Jun 2024 at 16:08)
I deleted my Answer to that post, since it wasn’t going to be accepted anyway. The documentation link I alluded to here (and cited in that ANswer) is Accuracy of Floating-Point Data.
.
John D'Errico
John D'Errico on 23 Jun 2024
Edited: John D'Errico on 23 Jun 2024
Even if a double was capable of storing 30 decimal digits, it would not matter anyway, since then we would hear people screaming that the 31st digit was wrong. No matter what you do, you cannot approximate most fractions in any finite storage form for the digits. And since all numbers with digits beyond the decimal point are essentially fractions, nobody will ever be happy if they expect exact storage. For example, 5 digits of precision, even assuming decimal storage, what is the fraction 1/3? Surely all we can do is use
x = 0.33333
But then what is 3*x? It is 0.99999.
How about the fraction 2/3? Ah, perhaps you will think you can win here, calling it 0.66667.
y = 0.66667
But then what is y - x? Surely y-x==x. But it cannot be so. y-x = 0.00001.
Any finite floating point arithmetic must exhibit exactly this type of failure. And until you learn that fact, and how to deal with it, you will be unhappy, always. Those numbers were stored as decimal digits. EXACTLY the same thing happens in any binary storage form.
Coming from the other direction, any storage form that will be sufficiently capable of storing infinite precision will be far too slow, so then people will be screaming about how slow is their code.

Sign in to comment.

Accepted Answer

halleyhit
halleyhit on 23 Jun 2024
Hi Luca, double, as a data type, is not as accurate as you expected. It would usually cause a relative error about 1e-16, which is small enough for most engineering. If you want to remove the error, you should use symbolic, and the code may look like
long = sym(2.305800000000000e+03);
short= sym(8.694000000000000e+02);
prof=sym(3.175200000000000e+03);
dail=long+short
dail = 
3.1752e+03
dail-prof
ans = 
0
  1 Comment
Walter Roberson
Walter Roberson on 24 Jun 2024
The conversion from double precision to rational does not always give the desired results. The numbers within the sym() call are interpreted as being double precision first, and then sym() is an active call to convert formats.
You are better off using something like
Q = @(v) sym(v);
long = Q(23058)/Q(10)^1;
short = Q(8694)/Q(10)^1;
prof = Q(31752)/Q(10)^1;
dail = long+short
dail = 
dail - prof
ans = 
0

Sign in to comment.

More Answers (0)

Community Treasure Hunt

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

Start Hunting!