Unexpected result of the "find" command in Matlab

  • Context: MATLAB 
  • Thread starter Thread starter hokhani
  • Start date Start date
  • Tags Tags
    Matlab
Click For Summary

Discussion Overview

The discussion revolves around an unexpected output from the "find" command in MATLAB, specifically when checking for equality in floating-point arithmetic. Participants explore potential causes and solutions related to the behavior of the "real" array and floating-point precision issues.

Discussion Character

  • Technical explanation
  • Debate/contested
  • Mathematical reasoning

Main Points Raised

  • One participant reports an unexpected error output of "error=4 7" while all elements of the "real" array appear to be 1.
  • Another participant suggests checking the output of the "real" vector and proposes alternative methods to find the indices.
  • A different participant mentions that the issue may stem from floating-point arithmetic and roundoff errors, indicating that exact equality checks can be misleading.
  • Evidence is presented showing that subtracting 1 from the "real" array does not yield all zeros, suggesting precision issues.
  • One participant recommends using a comparison tolerance to avoid the problem of floating-point inaccuracies.
  • Another participant recalls a similar issue encountered in optimization code related to small values close to zero.
  • Concerns are raised about the use of "real" as a variable name, which conflicts with a built-in MATLAB function, potentially causing further confusion.

Areas of Agreement / Disagreement

Participants express differing views on the cause of the unexpected output, with some attributing it to floating-point precision issues while others focus on the naming conflict with MATLAB functions. No consensus is reached on a single solution, and multiple approaches are suggested.

Contextual Notes

Participants note the limitations of floating-point arithmetic and the importance of using appropriate variable names to avoid conflicts with built-in functions.

hokhani
Messages
601
Reaction score
22
The program below gives "error=4 7" unexpectedly while all the arrays of "real" are 1! I would be grateful for any help.

Code:
kky=pi/(2*10000):pi/10000:1/658;
    ky=[-fliplr(kky) kky];
        kx=sqrt((1/658)^2-ky.^2);
expiphi_1=(658/1)*(kx+i*ky);
real=expiphi_1.*conj(expiphi_1)
error=find(real~=1)
 
Physics news on Phys.org
I've never seen this error. You could either find when real==1 then compute the complement or write a simple search loop yourself and see what you get. What is the output of the "real" vector?
 
HuskyNamedNala said:
I've never seen this error. You could either find when real==1 then compute the complement or write a simple search loop yourself and see what you get. What is the output of the "real" vector?

Thank you. What should I do to get rid of this problem?

The output of real and error are:
Code:
real =

    1.0000    1.0000    1.0000    1.0000    1.0000    1.0000    1.0000    1.0000    1.0000    1.0000error =

     4     7
 
HuskyNamedNala said:
I've never seen this error.
I tested it in another computer and got again to those unexpected values ,[4 7], for "error".
 
Try writing your own find loop. Also, check the data type for "real". If I remember correctly real is a command in MATLAB too, though I've since switched to Python.
 
The problem here is due to the nature of floating point arithmetic, where there can be roundoff errors in trying to represent numbers. You are comparing some floating point numbers for exact equality to a number. They are not exactly equal in a bit-for-bit sense, because the numbers came about as the result of arithmetic operations. So this type of comparison is discouraged.

Here is some proof, since if you subtract 1 from the array you don't get all zeros:

Code:
real-1

ans =

   1.0e-15 *

  Columns 1 through 4

                   0                   0                   0  -0.111022302462516

  Columns 5 through 8

                   0                   0  -0.111022302462516                   0

  Columns 9 through 10
                   0                   0

Inspecting the 3rd and 4th elements to 20 digits:

Code:
sprintf('%.20f',real(3))

ans =

1.00000000000000000000

sprintf('%.20f',real(4))

ans =

0.99999999999999989000

So what you need to do to avoid this problem is use a comparison tolerance. Something like the following:

Code:
tol = eps;
error = find(abs(real-1)>tol)

error =

   Empty matrix: 1-by-0
Future reading:
http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
 
  • Like
Likes   Reactions: hokhani and HuskyNamedNala
Ahh, good call. I remember running into a similar error when I was writing an optimization code and the search vector kept returning 0. It turns out it was ~10^-10
 
HuskyNamedNala said:
... Also, check the data type for "real". If I remember correctly real is a command in MATLAB too, though I've since switched to Python.

This is a good point, because "real" is a MATLAB function that returns the real part of a complex number. In general you shouldn't use names that override MATLAB functions, so just call this array something else, like "real1", "real_matrix" or "result".

If you were to execute the original code and then try to use the MATLAB real function, you might be disappointed that it no longer works:

Code:
a = 1- 5i

a =

  1.000000000000000 - 5.000000000000000i

real(a)
Subscript indices must either be real positive integers or logicals.

If you clear the variable, the MATLAB function works again:
Code:
real(a)

ans =

     1
 

Similar threads

  • · Replies 10 ·
Replies
10
Views
2K
  • · Replies 1 ·
Replies
1
Views
4K
  • · Replies 4 ·
Replies
4
Views
7K
  • · Replies 10 ·
Replies
10
Views
3K
  • · Replies 4 ·
Replies
4
Views
3K
  • · Replies 4 ·
Replies
4
Views
5K
  • · Replies 1 ·
Replies
1
Views
3K
  • · Replies 2 ·
Replies
2
Views
3K
  • · Replies 6 ·
Replies
6
Views
4K
Replies
2
Views
3K