why this logical expression is wrong?

Hi,

why this statment is wrong,

>> sind(30)==0.5

ans =

0

[Steven Lord]

Which release of MATLAB are you using?

Are you using the built-in sind function or one you've written or downloaded? In other words, what does this command return?

which -all sind

[mohammad fallah]

I'm using matlab 2016 a and also i'm using built-in function.

built-in (C:\Program Files\MATLAB\R2016a\toolbox\matlab\elfun\@double\sind) % double method

built-in (C:\Program Files\MATLAB\R2016a\toolbox\matlab\elfun\@single\sind) % single method

C:\Program Files\MATLAB\R2016a\toolbox\distcomp\parallel\@codistributed\sind.m % codistributed method

C:\Program Files\MATLAB\R2016a\toolbox\distcomp\gpu\@gpuArray\sind.m % gpuArray method

[Walter Roberson]

I seem to remember seeing a sind bug in the bug reports a couple of releases ago, but I cannot find that information now.

[Peter Jarosi]

I think it's not a bug, because it depends on the method of approximation. That's an interesting question how developers of sind() function fixed sind(30). Whether there is an if statement in the code of sind() in order to set sind(30) exactly 1/2. :-)

Answer 1

[Peter Jarosi]

because of the accuracy problem of a floating-point system

>> format longE

>> sind(30)

ans =

4.999999999999999e-01

Never, ever compare two floating-point numbers with == operand!

See also:

https://en.wikipedia.org/wiki/Floating-point_arithmetic#Machine_precision_and_backward_error_analysis

[Walter Roberson]

In current releases,

>> sind(30) - 0.5

ans =

0

[Peter Jarosi]

I use a little bit older version:

>> format longE

>> sind(30) - 0.5

ans =

-5.551115123125783e-17

It's my fault. Anyway, it's a programming principle to avoid floating-point numbers comparison.

[Walter Roberson]

>> help sind

sind Sine of argument in degrees.

sind(X) is the sine of the elements of X, expressed in degrees.

For integers n, sind(n*180) is exactly zero, whereas sin(n*pi)

reflects the accuracy of the floating point value of pi.

[mohammad fallah]

tanks

but I try this before in this way:

format long

>> sind(30)

ans =

0.500000000000000

as you can see I get same result!

[Walter Roberson]

format long rounds off to 15 decimal places instead of all 16. You need to subtract 0.5 to see the difference between the sind(30) result and 0.5

[Peter Jarosi]

Sometimes we can be lucky with floating-point numbers (depending on the function or the version of our system) but never sure! That's why it's better to compare two floating-point numbers within a tolerance:

tolerance = 1e-10;
abs(a - b) < tolerance;

[Peter Jarosi]

or use Matlab built-in eps:

https://www.mathworks.com/help/matlab/ref/eps.html

[mohammad fallah]

you're right.

thank you

[Peter Jarosi]

You're welcome! Thank you for accepting my answer.

[Peter Jarosi]

I voted your question. It's a million dollar question, and the problem is general, not Matlab's fault.

[Walter Roberson]

The result of sind(30) should be exactly 1/2, but it appears that in some older releases it was not exactly that.

It is generally better to not compare for floating point equality except when you know that the exact bit-pattern occurs somewhere. For example, it is fair to test

A = min(B);
B == A

because you know that A will be a bit-for-bit copy of one of the values that is in B. (Well, except for some obscure cases involving non-default nan values... and in those cases, nan == nan is always false anyhow.)

Answer 2

[Steven Lord]

This is a bug. See Bug Report 1839169.

[Peter Jarosi]

How did you fix it? Did you use a better approximation method (for instance longer Taylor series) or just put an if statement in the code of function sind()? :-)

(I'm joking)