why does matlab invent decimal numbers?

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
%}

[Star Strider]

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]

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.

Answer 1

[halleyhit]

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

[Walter Roberson]

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