We found a possible bug in our Matlab

1 次查看(过去 30 天)
Sometimes we encounter a numerical problem e.g:
find([1.1:0.01:1.2]==1.14)
ans =
Empty matrix: 1-by-0
The cause is most likely numerical as if we add eps to 1.14, it suddenly works for 1.14: >> find([1.1:1e-2:1.2]==1.14+eps)
ans =
5
Please let us know if you have a fix
  1 个评论
Stephen23
Stephen23 2017-1-15
编辑:Stephen23 2017-1-15
"We found a possible bug in our Matlab"
Aaaah, the one millionth beginner has found this bug in MATLAB! It must be MATLAB's fault! Or perhaps instead today is good day to learn about floating point numbers (and how this is not an bug in MATLAB)?

请先登录,再进行评论。

采纳的回答

John D'Errico
John D'Errico 2017-1-15
编辑:John D'Errico 2017-1-15
NO. This is not a bug in MATLAB. This is only a bug in your understanding of floating point numbers and how to work with them.
Essentially, NEVER test for exact equality of floating point numbers (integers and floating point integers are ok.)
  4 个评论
Stephen23
Stephen23 2017-1-15
编辑:Stephen23 2017-1-15
"I thought that matlab found some way to overcome this problam."
What problem? This makes as much sense as saying that someone should "fix" giraffes: sorry, but giraffes are how they are, and do not need "fixing". Floating point numbers do not need "fixing" either. This is how numbers are stored in computers. If you want to work with them then you need to learn how.
"I found a way to do that:"
"find(round([1.1:1e-2:1.2],2)==1.14)"
Just to let you know that you should have paid more attention to what these answers tell you, because your "solution" is extremely fragile. Pay particular attention to the "do not test for equivalence of floating point numbers" statements.
John D'Errico
John D'Errico 2017-1-15
编辑:John D'Errico 2017-1-15
Those darn broken giraffes.
This still ahs the same "problem".
find(round([1.1:1e-2:1.2],2)==1.14)
As I said, never test for equality of something with a float like 1.14. Your test will probably fail.
Had you made the test as:
find( abs([1.1:1e-2:1.2] - 1.14) < 2*eps(1.14))
ans =
5
That would have been a valid solution.

请先登录,再进行评论。

更多回答(2 个)

Image Analyst
Image Analyst 2017-1-15
Not to beat a dead giraffe, but you can also find the same information about comparing floating point numbers in the FAQ: http://matlab.wikia.com/wiki/FAQ#Why_is_0.3_-_0.2_-_0.1_.28or_similar.29_not_equal_to_zero.3F

Walter Roberson
Walter Roberson 2017-1-15
This is not a bug. When you use == you are asking for exact comparison right down to the last bit. You are assuming that computations are carried out in decimal so that 0.1 and 0.01 are exactly represented, but calculations are carried out in binary which has no exact representation for 1/10 (exactly the same way that decimal has no exact finite representation for 1/7). The error in representation builds up when you use the : operator, which is not going to be adding exactly 1/100 each time, only a value very close to 1/100. And the starting value 1.1 also cannot be exactly represented in binary.
The result of this is that the : operation is going to produce a number that is close to 1.4 but not exactly equal to it and not exactly equal to how MATLAB converts 1.4 to binary. With == needing exact match, the comparison fails.
Try
format long g
(1.1:0.01:2) - 1.4
and you will see that one of the values is close to 0 but not exactly 0. If the value was exactly there then you would get a 0
You should avoid comparing floating point numbers for exact equality unless you have extracted the numbers from the same array. See ismembertol()
  3 个评论
John D'Errico
John D'Errico 2017-1-15
itamar - No. You think you solved it. But you did not. See my comment above.
itamar luzon
itamar luzon 2017-1-15
Thanks Jhon, i saw your comment, i tested my answer the same way, i just didn't write it. Anyway i will be carefull next time that i will use flouting point numbers.

请先登录,再进行评论。

类别

Help CenterFile Exchange 中查找有关 Logical 的更多信息

产品

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by