MATLAB: Problem with Greater Than and addition

additioncomparisongreater thanMATLAB

I haven't checked this in other versions, but in Matlab 2015a, or 2014b, or 2014a, try the following:
myVar = 255.22;
myVar2 = myVar + 1;
while (myVar2 - myVar) > 1
  disp('Why does this run forever?')
  myVar2 = myVar + 1;
end
The above is my problem, boiled down to the least amount of code possible. I'm trying to evaluate some test data and apply a ramp-limiting algorithm. The number that I get back is the number from my sensor. The particular value I'm using here is an actual sensor reading that causes a problem with the algorithm.
If myVar2 is defined to be myVar + 1, then how can myVar2 – myVar ever be greater than one??
There are other values that cause this glitch, at different levels of precision (for example, 63.211666666666666 also causes the problem), but the number above, 255.22, seems to be the one of the most confounding. It's a normal-looking number that doesn't have an excessive number of decimal values. I don't know what to do.
63.460000000000001 is another example. I had initially thought that maybe there were too many digits after the decimal, and while it's extremely frustrating that MATLAB can't handle that, I thought maybe I could round or truncate the number to something that works better. This is actually the current workaround, but it is still not correct because it still doesn't handle 255.22 or any of the otherwise normal-looking numbers below, and this is devastating my project.
Some more innocuous-looking numbers that Matlab can't seem to handle are:
255.6575
255.345
511.94
127.675
255.965
511.1275
255.84
255.845
I could rant, but I won't. I'll just leave this sample set of numbers here and hope someone knows how to fix this. At this point, given that a number like 511.94 fails this test, rounding or truncating is not an acceptable answer.
:EDIT:
Roger Stafford posted below that I have to allow a "tiny margin" to account for the fact that Matlab does binary math and not decimal math. This comment brings up a few more questions:
  1. What is the exact value of the "tiny margin" that needs to be allowed for? I'm not really at liberty to discuss the particulars of the project, but digits after the decimals matter (especially in a number like 255.22). I'm using a commercial Matlab license on a commercial project and do not want to truncate without justification.
  2. How should the "tiny margin" be used? I tried adding "myVar = myVar (+/-) 0.01;" before the myVar2 assignment in the while loop above, and wound up with a range of numbers from 255 to 256 that all failed because adding 0.01 wound up actually giving a number like 255.22999999999999.
  3. How do I tell, in advance, when this is going to be an issue? 255.2 doesn't have this problem, 255.222 doesn't have this problem, 255.2222 doesn't have this problem – only 255.22 does.
  4. Is there a way to force decimal math (instead of binary math) and skirt the whole problem?

Best Answer

You need to be aware that your computer does its computation in binary digits not decimal digits. Hence it cannot represent 255.22 exactly and uses the binary fraction nearest that value. When you add 1, the resulting difference may not be a precise 1. Therefore you must allow a tiny margin for rounding error in your 'while' condition. This issue is a very old one on this forum.
Related Question