Checking if a value is equal to zero or no ? with the problem of floating-point numbers !

I have tables like:

 A = [0.0850    0.2130    0.1480    0.2220    0.2430    0.0890]
 B= [0.08950    0.25130    0.12480    0.2220    0.2430    0.0890]
 ...etc

I want to test if the somme of each table is equale to one or no. For example the table A. sum(A)=1

but when I test:

if (sum(A(:))==1)
    "yes";
end

the results is always "no". but the sum of A = 1.000 ... any soulition ?

I won't remove the point.

Answer 1

[KALYAN ACHARJYA]

%%
A = [0.0850    0.2130    0.1480    0.2220    0.2430    0.0890]
if logical(sum(A(:)))==1
    "yes"
end

More:

A =
    0.0850    0.2130    0.1480    0.2220    0.2430    0.0890
>> result=sum(A(:))
result =
    1.0000
>> result==1
ans =
  logical
   0

Must read:

https://www.mathworks.com/matlabcentral/answers/20830-1-0010-does-not-equal-1-0010

https://www.mathworks.com/matlabcentral/answers/39723-relational-operators-issue-1-is-not-equal-to-1-000

https://www.mathworks.com/matlabcentral/answers/258463-how-to-comparison-decimal-numbers

[Rahim Rahim]

If I changed the values of the A, for example

A =
    0.9850    0.2130    0.1480    0.2220    0.2430    0.0890

and I test again, it gime bad results, A ~= 1

But logical gave me faulsse results.

[Rahim Rahim]

For example,

C=4

Constraint1= logical(C) == 1;

C is not equal 1, but when we use your method, he give me bad results

[KALYAN ACHARJYA]

As this is '==' logical operator, as 0.999 or 1.000999, both consider as logical 1. The logical data type represents true or false states using the numbers 1 and 0, If you somehow wish to get the results, therfore I have shown that way (If not please ignore that).

The main issue with floating points, The main issue is "Why 1.000 is not equal to 1" hope you visited the suggested links.

Answer 2

[Walter Roberson]

sum(A) - 1

   ans =

     -1.11022302462516e-16

MATLAB uses ieee 754 binary double precision representation, which is the hardware representation used in the great majority of modern general purpose CPUs (but embedded systems might use different methods.) It is not able to exactly represent 1/10 for the same mathematical reason that finite decimal calculations are not able to exactly represent 1/3. Your entry 0.0850 is not represented as exactly equal to 85/1000 and instead is represented by a value equal to 0.08500000000000000610622663543836097232997417449951171875

Imagine you are trying to represent 1/3 exactly in finite decimal. Suppose you use 4 decimal places: 0.3333. Multiply that by 3 and we get 0.9999 which is not exactly 1. Okay so 4 decimal places was not enough, how about 8? 0.33333333 * 3 = 0.99999999 so that was not good enough either. How about 21? 0.333333333333333333333 * 3 = 0.999999999999999999999. No matter how many finite decimal places you use, it does not work out. You need to use an infinite number of decimal places for it to work out. (Odd mathematical fact, 0. followed by an infinite number of 9s, is equal to 1)

You are accustomed to these kinds of limitations in decimal, even if you do not tend to think about them much. Decimal can exactly represent the fraction A/B that is in lowest terms if B can be factored entirely into 2s and 5s, such as 7/200, but not 7/201. Finite binary is slightly more limited and can exactly represent if B can be factored entirely into 2s - so 7/256 but not 7/250. It is the same mathematical reason that finite decimal has limitations.

It is not a bug in MATLAB.

Answer 3

[Steven Lord]

Testing for exact, down-to-the-last-bit equality with == can be problematic. Instead, the general recommendation is to check for equality to within a tolerance.

x = 1/3;
y = x+x+x+x;
z = y-1;
x == z % false

ans = logical
   0

abs(x-z) <= 1e-12 % true

ans = logical
   1