Matlab floating point precision.

My question pertains to matlab precision. I encountered this problem I have a long time series of 549354 record. and I am looking at values the end point and a point somewhere in the beginning.

First point Tcum(64996) and the second point is Tcum(549354)

Q1 = Tcum(64996) which is actually = 0.048229777756042
Q2 = Tcum(549354) which is actually = 1.060933335844769e+05
X2 = Q2-Q1;
Check = Q2-X2;

Now I expected Check to be identically equal to Q1; these are the values I get.

Check =  0.048229777748929
Q1    =  0.048229777756042

They are clearly different. Is this behaviour normal and is a result of dealing with largely varying magnitude in numbers? Or am i doing something wrong here?

[David Fletcher]

See the docs on floating point relative accuracy (eps)

Answer 1

[John D'Errico]

Never trust the least significant bits of a floating point number, at least unless you know enough about the extent that you can trust them. But in general, don't.

A double precision floating point number carries roughly 16 digits, actually 52 binary bits of precision.

What happens when you add two numbers that are of different magnitude?

X0 = 1/3
X0 =
         0.333333333333333

So X0 is 1/3. Not exactly because we cannot represent the fraction 1/3 exactly in binary. But that is not really pertinent here.

sprintf('%0.55f',X0)
ans =
    '0.3333333333333333148296162562473909929394721984863281250'

Suppose we add and subtract delta?

delta = 100000.1
delta =
                  100000.1

X1 = X0 + delta - delta
X1 =
       0.333333333328483

What happened? We added a number that was more than 1e5 times as large as X0. Stored in a double, that means we lose the bottom 5 digits of the sum. Subtracting delta off again, does not help, because we already lost that information. Once information is lost, it cannot be magically regained.

[Pappu Murthy]

Thanks for the clarification and the answer. I understand now.

[Sergey Kasyanov]

Are there any embedded instruments for detect when digits are losted?

[Walter Roberson]

Every floating point operation that is not working on integers and is not multiplying by 0 or 1, loses digits.

There are techniques for estimating the number of digits lost, by examining the operands and knowing something about the operation (might involve constructing some taylor series). The techniques are a bit of a pain. And they tend to over-estimate because there are situations where you can prove that some losses compensate.

[John D'Errico]

MATLAB, as well as many other tools that work in floating point arithmetic, uses a binary storage mode. Yes, I know that aliens always seem to use ternary in the movies. But here on earth, it is binary. :)

That fact is important, because we use decimal numbers when we work. The only decimal fractions that can be represented exactly in binary are those that can be formed as sums of negtive powers of 2, and the limit on that for a double are numbers that can be represented in 52 bits.

So 1/2 or 3/4=1/2+1/4, are both represented exactly as doubles.

However, to know when digits are lost is simple. If it is not a pure power of 2, or a sum of them (within limits defined by a 52 bit approximation) then digits are ALWAYS lost.

[Walter Roberson]

 then digits are ALWAYS lost

And that's just for addition. (By the way, I did neglect the case of adding 0, above: that does not lose precision.)

For multiplication, if you are not multiplying or dividing by a pure power of 2, then you lose digits, except in some cases where the precision needed to represent the inputs is less than half of double precision precision, in which case the result might fit within double precision without loss of digits.

For any calculation such as sin() or sqrt() or exp() you will lose digits.

A couple of years ago, I encountered a paper that showed that for some calculations, no matter how many digits of floating point precision you used, that there are some calculations where the potential relative error is at least 100%. Unfortunately the details are not coming to mind at the moment.