Possible bug when generating vectors with a fixed step
in [Matlab]
|
From: Derek O'Connor on 11 Jan 2010 05:17 "Bogdan Cristea" <cristeab(a)gmail.com> wrote in message <hid6ul$i6c$1(a)fred.mathworks.com>... > The following code gives the wrong result: > > x = 0:0.1:5; > find(x==1.4) > > The output of the find function is an empty matrix. Should be this considered as a bug ? -------------------------------- The real and more general problem is dividing an interval [a,b] into steps whose length is not representable in IEEE floating point binary arithmetic. In your example a=0, b=5 are representable, but the step=0.1 is not representable. What is so special about 0.1 or 0.01? In most problems you are free to choose the step, within limits, so why not choose a representable step, such as 1/8, 1/32, etc. If you must use 0.1, 0.01, etc., then I suggest you wait until Intel and AMD bring out processors that implement the IEEE standard for decimal arithmetic. Until then you are stuck with binary arithmetic. Software solutions using tolerances etc. are messy, error-prone, and time-consuming. The Patriot Missile disaster in which 28 soldiers were killed, was caused by counting time in tenths of a second. Derek O'Connor
From: Steven Lord on 11 Jan 2010 10:35
"Bogdan Cristea" <cristeab(a)gmail.com> wrote in message news:hieg9r$ra3$1(a)fred.mathworks.com... > "Jan Simon" <matlab.THIS_YEAR(a)nMINUSsimon.de> wrote in message > <hid9o3$e29$1(a)fred.mathworks.com>... >> Dear Bogdan! >> >> > The following code gives the wrong result: x = 0:0.1:5; >> > find(x==1.4) >> > The output of the find function is an empty matrix. Should be this >> > considered as a bug ? >> >> Have you read the FAQ as suugested e.g. on the MathWorks web interface of >> this newsgroup: "Check if your question is answered in the >> comp.soft-sys.matlab FAQ" ? >> There you find: >> http://matlabwiki.mathworks.com/MATLAB_FAQ#Why_is_0.3-0.2-0.1_not_equal_to_zero_.28or_similar.29.3F >> >> So this is not a bug, but the typical, expected and intented behaviour of >> floating point numbers. >> >> Kind regards, welcome to this newsgroup, Jan > > Yes, you have right, I have forgotten about how the floating point numbers > are represented in a PC. Nevertheless, in a high level language, the > tolerance when comparing numbers could be taken into account. That would eliminate one instance of this type of confusion, but more would be lurking in the wings waiting for their time in the spotlight. y = floor(0.3/0.1) If you were to perform this computation in exact arithmetic, the answer is obviously 3. But since 0.1 and 0.3 are not exactly representable as double (the cause of the problem in your initial post) the actual answer is y = 2. z1 = 1; z2 = 1+1e-20; z3 = z2-z1 Again, in exact arithmetic, z3 is 1e-20. In double-precision floating point arithmetic, the correct answer is z3 = 0, because z2 is exactly 1. Borrowing an example from Cleve's article linked in the FAQ entry above: y = 4/3; x = y-1; z = 3*x; epsilon = 1-z % not 0 I could come up with MANY examples like this, probably one for just about every function in MATLAB, where the answer that may seem obvious (from our experience with exact arithmetic) is not what MATLAB returns. None of the above are bugs. -- Steve Lord slord(a)mathworks.com comp.soft-sys.matlab (CSSM) FAQ: http://matlabwiki.mathworks.com/MATLAB_FAQ |