why does matlab invent decimal numbers?
2 views (last 30 days)
Show older comments
long = 2.305800000000000e+03;
short= 8.694000000000000e+02;
prof=3.175200000000000e+03
dail=long+short
dail-prof
%{
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
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
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.
Accepted Answer
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-prof
1 Comment
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 - prof
More Answers (0)
See Also
Categories
Find more on Logical in Help Center and File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!