So what is your problem? If you think the result should always be an exact integer, that just means you don't appreciate floating point arithmetic.
Perhaps you wonder why the last of those computations does give an exact integer. That happens because 0.125 is EXACTLY representable as a binary number, thus 2^-3. We could write it in the form of
0.00100000000000000000000000...
in binary bits.
So when you multiply it by 2*100, you turn the result into the exact integer 25.
The other results are NOT exactly representable in binary. For example, the decimal number 0.145 looks like
0.0010010100011110101110000101000111101011100001010001111...
as a repeating binary form, where each 1 in that expansion represents a negative power of 2.
This is no different from the fact that you cannot write the fraction 1/3 as a terminating decimal number.
That means you cannot expect all of those results to always be exact integers.
sprintf('%0.55f',0.145)
ans =
'0.1449999999999999900079927783735911361873149871826171875'
sprintf('%0.55f',2*0.145*100)
ans =
'28.9999999999999964472863211994990706443786621093750000000'
29 == 2*0.145*100
ans =
logical
0
In a binary form, we might write what MATLAB generates for 2*0.145*100 using this expansion:
11100.111111111111111111111111111111111111111111111111
Whereas we know that 29 is:
dec2bin(29)
ans =
'11101'
So the result is off by one bit down at the least significant bit of the number.
All of this is due, not to MATLAB, but to the IEEE representation of floating point numbers, used by most computing languages.
