Matlab gave me a right value for PA< PB< PZa ,PZb, Pzc but they said the wrong thing about conclusion, they said " does not equl. However, it will equal

fprintf('\n I1= %d \n I2 = %d \n I3 =%d');

Imag = abs(I)

Ideg = radtodeg(angle(I))

PA = abs(V(1))*abs (I(1))*cos(angle(V(1)) - angle (I(1)));
PB = abs(V(3))*abs (I(3))*cos(angle(V(3)) - angle (I(3)));

PZa = abs(V(1)) * abs ( I (1) - I (2)) *cos (angle(V(1)) - angle ((I(1) - I (2) )));

PZb = abs (V (3)) * abs ( I(3) - I(2) ) * cos ( angle ( V(3) ) - angle( (I(3) - I(2) )));
PZc = abs( V(1) + V(3) ) * abs (I (2 )) * cos ( angle ( V(1) +  V(3) ) - angle ( I (2 )) );  

fprintf(' \n PA =  %d \n PB = %d \n PZa = %d \n PZb = %d \n PZc = %d \n ', PA, PB, PZa, PZb, PZc);


format default;
if  ( (PA + PB) == (PZa + PZb + PZc) );
    fprintf (' \n %d + %d equal %d + %d + %d \n', PA, PB, PZa, PZb, PZc);

else
    fprintf ('\n %d + %d does not equal %d + %d + %d \n', PA, PB, PZa, PZb, PZc);

end

Answer 1

[Fangjun Jiang]

It is not robust to use == operator to compare two floating-point data. Search for "floating point data equal comparison" and you will learn why.

isequal(1.1+2.2, 3.3)

ans = logical
   0

isapprox(1.1+2.2, 3.3)

ans = logical
   1

[Thinh]

can you say more about it

It calculates right, but it should be " equal " instead of " does not equal " for the conclusion.

[Walter Roberson]

Consider

a = 0.1 + 0.2 - 0.3

a = 5.5511e-17

Mathematically the result should be zero, but in floating point calculation the result is non-zero.

This is because in floating point calculation,

fprintf('%.999g\n', 0.1, 0.2, 0.3);

0.1000000000000000055511151231257827021181583404541015625
0.200000000000000011102230246251565404236316680908203125
0.299999999999999988897769753748434595763683319091796875

the closest floating point approximation to 0.1 is slightly above 0.1, and the closest floating point approximation to 0.2 is slightly above 0.2 but the closest floating point approximation to 0.3 is slightly below 0.3 . Adding the 0.1 approximation to the 0.2 approximation is going to give a result above 0.3 which is different than the below 0.3 approximation that 0.3 generates.

Thus, whenever you have two floating point calculations that follow different calculation paths, the results might not be the same in floatiing point, even though the results might theoretically be the same mathematically.

Answer 2

[Steven Lord]

I was going to execute this code so we could see what your fprintf statements displayed, but you did not define the variables I and V.

But I'm 95% sure that what you're seeing is a consequence of how you're displaying the values versus what is stored in the variables. What leads you to believe that PA, PB, etc. are integer values? From the description of the formatSpec input argument on the documentation page for the fprintf function, the %d formatting operator is used for "Integer, signed". At best if your values are not integers you'll get something closer to %e.

fprintf("%d", pi)

3.141593e+00

In addition, just because two numbers are displayed the same doesn't mean their stored values are equal.

format
x = 1 + 1e-6

x = 1.0000

y = 1+1e-8

y = 1.0000

x and y are displayed the same, but they are not the same value.

x == y % false

ans = logical
   0

x - y % not zero

ans = 9.9000e-07

BTW, the setting specified by the format function has no effect on the fprintf function.

format bank % 2 decimal places
P = pi

P = 
          3.14

fprintf("%1.12f", P)

3.141592653590