# floating point arithmetics, mathlab's interpretation of a . after a number

2 views (last 30 days)
David Ortega on 17 Oct 2020
Commented: Walter Roberson on 19 Oct 2020
Regarding mathlab's reading of the . operator after a number I know that, for example, that if i introduce it when miltuplying two matrixes A.*B of the same dimentions Mathlab will yield a matrix that has multiplied each entry like so A[i,i]*B[i,i].
When introducing values
the following values:
h=1./2.;
x=2./3.-h;
y=3./5.-h;
e=(x+x+x)-h;
printing e yields -1.110223024625157e-16
but when I do x+x+x it yields = 0.5
Why doesn't e yield 0?
I know it has to do with something of the sort of the matrix problem but i do not know for certain and floating point arithmetic but i do not know for certain.

Stephen on 17 Oct 2020
Edited: Stephen on 17 Oct 2020
"Why doesn't e yield 0?"
Because most of your values cannot be exactly represented using binary floating point numbers.
The values stored in your computer's memory are only approximations of those values (to a finite precision), and that approximation means that they include some floating point error. So when you perform arithmetic operations on those values, sometimes that floating point error accumulates during the operation.. .and in some cases, that accumulation can cancel-out completely (important note: this cancelation does not change the precision of the output!). This is exactly what your two examples show: one of the operations happens to accumulate some error which remains in the output, another operation happens to cancel out the error so that the output looks like it is "exact" (in fact in both cases the output precision is much the same).
Lets have a look at the exact values that your computer is calculating with:
>> num2strexact(x)
ans =
0.16666666666666662965923251249478198587894439697265625
>> num2strexact(y)
ans =
9.999999999999997779553950749686919152736663818359375e-2
Learn about binary floating point numbers and how they behave:
This is worth reading as well:
David Ortega on 19 Oct 2020
thanks a lot! i'll look into it!

Matlab sotere double numbers in 8 bytes (64 bits) . So if you do some aritmatic operations, there is an error due to the limits on the space for each number I you can see some small numbers instead of 0. The number 0.5 in binary format is exact and you can see 0.5 as a result. Also, it is not necessary to use . after numbers. 1. is the same as 1
##### 2 CommentsShowHide 1 older comment
Walter Roberson on 19 Oct 2020
Side note: There are cases inside symbolic expressions where 1. is not the same as 1
For example,
>> subs(str2sym({'x^(1/2)', 'x^(1/2.)'}),x,3)
ans =
[ 3^(1/2), 1.7320508075688772935274463415059]
The 2. compared to plain 2 made the difference between treating the calculation as an exact system or as a floating-point calculation to be approximated.