EDU>> intmin
ans =
-2147483648
EDU>> abs(intmin)
ans =
2147483647
How is this possible? There must be some sort of overflow or the definitions of these functions are mingling in strange ways.
For 2's complement signed integers of 32 bits, intmin is 0x80000000, or indeed -2147483648. However, intmax is 0x7FFFFFFF, which is only 2147483647. This means that the negation of intmin would be 2147483648, which can't be represented in 32-bit signed integers.
MATLAB actually does something odd. Under the normal rules of 2's complement, 0 - 0x80000000 should give 0x80000000 again. However, according to MATLAB, 0 - 0x80000000 = 0x7FFFFFFF. This should explain why abs(intmin) = intmax holds for MATLAB (but not necessarily in other languages).
This oddity has an interesting side-effect, however: you can assume that abs never returns a negative number.
In order to encode zero, there must be asymmetry among positive/negative two's complement integers.
Indeed, you are seeing integer overflow (saturation).
For each integer data type, there is a largest and smallest number that you can represent with that type:
When the result of an expression involving integers exceeds the maximum (or minimum) value of the data type, MATLAB maps the values that are outside the limit to the nearest endpoint. This saturation behavior explains what you are seeing rather than a weird case of overflow in binary representation (which "wraps around" in 2's complement).
Example:
>> x = int8(100)
x =
100
>> x + x
ans =
127
Related
I was testing a operation like this:
[input] 3.9/0.1 : 4.1/0.1
[output] 39 40
don't know why 4.1/0.1 is approximated to 40. If I add a round(), it will go as expected:
[input] 3.9/0.1 : round(4.1/0.1)
[output] 39 40 41
What's wrong with the first operation?
In this Q&A I go into detail on how the colon operator works in MATLAB to create a range. But the detail that causes the issue described in this question is not covered there.
That post includes the full code for a function that imitates exactly what the colon operator does. Let's follow that code. We start with start = 3.9/0.1, which is exactly 39, and stop = 4.1/0.1, which, due to rounding errors, is just slightly smaller than 41, and step = 1 (the default if it's not given).
It starts by computing a tolerance:
tol = 2.0*eps*max(abs(start),abs(stop));
This tolerance is intended to be used so that the stop value, if within tol of an exact number of steps, is still used, if the last step would step over it. Without a tolerance, it would be really difficult to build correct sequences using floating-point end points and step sizes.
However, then we get this test:
if start == floor(start) && step == 1
% Consecutive integers.
n = floor(stop) - start;
elseif ...
If the start value is an exact integer, and the step size is 1, then it forces the sequence to be an integer sequence. Unfortunately, it does so by taking the number of steps as the distance between floor(stop) and start. That is, it is not using the tolerance computed earlier in determining the right stop! If stop is slightly above an integer, that integer will be in the range. If stop is slightly below an integer (as in the case of the OP), that integer will not be part of the range.
It could be debated whether MATLAB should round the stop number up in this case or not. MATLAB chose not to. All of the sequences produced by the colon operator use the start and stop values exactly as given by the user. It leaves it up to the user to ensure the bounds of the sequence are as required.
However, if the colon operator hadn't special-cased the sequence of integers, the result would have been less surprising in this case. Let's add a very small number to the start value, so it's not an integer:
>> a = 3.9/0.1 : 4.1/0.1
a =
39 40
>> b = 3.9/0.1 + eps(39) : 4.1/0.1
b =
39.0000 40.0000 41.0000
Floating-point numbers suffer from loss of precision when represented with a fixed number of bits (64-bit in MATLAB by default). This is because there are infinite number of real numbers (even within a small range of say 0.0 to 0.1). On the other hand, a n-bit binary pattern can represent a finite 2^n distinct numbers. Hence, not all the real numbers can be represented. The nearest approximation will be used instead, resulted in loss of accuracy.
The closest representable value for 4.1/0.1 in the computer as a 64-bit double precision floating point number is actually,
4.1/0.1 ≈ 40.9999999999999941713291207...
So, in essence, 4.1/0.1 < 41.0 and that's what you get from the range. If you subtract, for example, 41 - 4.1/0.1 = 7.105427357601002e-15. But when you round, you get the closest value of 41.0 as expected.
The representation scheme for 64-bit double-precision according to the IEEE-754 standard:
The most significant bit is the sign bit (S), with 0 for positive numbers and 1 for negative numbers.
The following 11 bits represent exponent (E).
The remaining 52 bits represents fraction (F).
In MATLAB,
>> format hex; 3/10, 3*0.1
ans =
3fd3333333333333
ans =
3fd3333333333334
>> 3/10 - 3*0.1
ans =
bc90000000000000
Is this result predictable? i.e. I can follow some rules of floating point arithmetic, and get 3/10 = 3d3333333333333, 3*0.1 = 3d3333333333334 again by hand.
The rules are:
In MATLAB, unless specified otherwise (via constructors), all literals have double precision in the sense of IEE754 standard: http://www.mathworks.com/help/matlab/matlab_prog/floating-point-numbers.html
All arithmetic operations are executed according to the usual precedence rules: http://www.mathworks.com/help/matlab/matlab_prog/operator-precedence.html
When mixing numeric types with double in an arithmetic operation, MATLAB converts the double to the other numeric type before executing the operation—as opposed to C, for example, which does the other way around.
By using these rules you can pretty much predict the results of any arithmetic expression (always little endian memory layout, bit patterns are two's complement for signed integers and IEEE754 for floats). The alternative is to let MATLAB apply the rules for you; the results will be consistent and repeatable.
The reason is that when creating the binary representation for 0.1 a roundup has occurred, introducing a small error:
>> 0.1
ans =
3fb999999999999a
There should be infinitely many of those 9s in the end but we cut it and round up the last digit. The error is small but becomes significant when you multiply by 3
>> 3*0.1
ans =
3fd3333333333334
When correctly calculated by division this last digit shouldn't be 4:
>> 3/10
ans =
3fd3333333333333
It is interesting to see that this error is not big enough to cause a problem when we multiply by some other number smaller than 3 (the threshold is not exactly 3 though):
>> 2.9/10
ans =
3fd28f5c28f5c28f
>> 2.9*0.1
ans =
3fd28f5c28f5c28f
I'm aware that double is the default data-type in MATLAB.
When you compare two double numbers that have no floating part, MATLAB is accurate upto the 17th digit place in my testing.
a=12345678901234567 ; b=12345678901234567; isequal(a,b) --> TRUE
a=123456789012345671; b=123456789012345672; isequal(a,b) --> printed as TRUE
I have found a conservative estimate to be use numbers (non-floating) upto only 13th digit as other functions can become unreliable after it (such as ismember, or the MEX functions ismembc etc).
Is there a similar cutoff for floating values? E.g., if I use shares-outstanding for a company which can be very very large with decimal places, when do I start losing decimal accuracy?
a = 1234567.89012345678 ; b = 1234567.89012345679 ; isequal(a,b) --> printed as TRUE
a = 123456789012345.678 ; b = 123456789012345.677 ; isequal(a,b) --> printed as TRUE
isequal may not be right tool to use for comparing such numbers. I'm more concerned about up to how many places should I trust my decimal values once the integer part of a number starts growing?
It's usually not a good idea to test the equality of floating-point numbers. The behavior of binary floating-point numbers can differ drastically from what you may expect from base-10 decimals. Consider the example:
>> isequal(0.1, 0.3/3)
ans =
0
Ultimately, you have 53 bits of precision. This means that integers can be represented exactly (with no loss in accuracy) up to the number 253 (which is a little over 9 x 1015). After that, well:
>> (2^53 + 1) - 2^53
ans =
0
>> 2^53 + (1 - 2^53)
ans =
1
For non-integers, you are almost never going to be representing them exactly, even for simple-looking decimals such as 0.1 (as shown in that first example). However, it still guarantees you at least 15 significant figures of precision.
This means that if you take any number and round it to the nearest number representable as a double-precision floating point, then this new number will match your original number at least up to the first 15 digits (regardless of where these digits are with respect to the decimal point).
You might want to use variable precision arithmetics (VPA) in matlab. It computes expressions exactly up to a given digit count, which may be quite large. See here.
Check out the MATLAB function flintmax which tells you the maximum consecutive integers that can be stored in either double or single precision. From that page:
flintmax returns the largest consecutive integer in IEEE® double
precision, which is 2^53. Above this value, double-precision format
does not have integer precision, and not all integers can be
represented exactly.
I use mod() to compare if a number's 0.01 digit is 2 or not.
if mod(5.02*100, 10) == 2
...
end
The result is mod(5.02*100, 10) = 2 returns 0;
However, if I use mod(1.02*100, 10) = 2 or mod(20.02*100, 10) = 2, it returns 1.
The result of mod(5.02*100, 10) - 2 is
ans =
-5.6843e-14
Could it be possible that this is a bug for matlab?
The version I used is R2013a. version 8.1.0
This is not a bug in MATLAB. It is a limitation of floating point arithmetic and conversion between binary and decimal numbers. Even a simple decimal number such as 0.1 has cannot be exactly represented as a binary floating point number with finite precision.
Computer floating point arithmetic is typically not exact. Although we are used to dealing with numbers in decimal format (base10), computers store and process numbers in binary format (base2). The IEEE standard for double precision floating point representation (see http://en.wikipedia.org/wiki/Double-precision_floating-point_format, what MATLAB uses) specifies the use of 64 bits to represent a binary number. 1 bit is used for the sign, 52 bits are used for the mantissa (the actual digits of the number), and 11 bits are used for the exponent and its sign (which specifies where the decimal place goes).
When you enter a number into MATLAB, it is immediately converted to binary representation for all manipulations and arithmetic and then converted back to decimal for display and output.
Here's what happens in your example:
Convert to binary (keeping only up to 52 digits):
5.02 => 1.01000001010001111010111000010100011110101110000101e2
100 => 1.1001e6
10 => 1.01e3
2 => 1.0e1
Perform multiplication:
1.01000001010001111010111000010100011110101110000101 e2
x 1.1001 e6
--------------------------------------------------------------
0.000101000001010001111010111000010100011110101110000101
0.101000001010001111010111000010100011110101110000101
+ 1.01000001010001111010111000010100011110101110000101
-------------------------------------------------------------
1.111101011111111111111111111111111111111111111111111101e8
Cutting off at 52 digits gives 1.111101011111111111111111111111111111111111111111111e8
Note that this is not the same as 1.11110110e8 which would be 502.
Perform modulo operation: (there may actually be additional error here depending on what algorithm is used within the mod() function)
mod( 1.111101011111111111111111111111111111111111111111111e8, 1.01e3) = 1.111111111111111111111111111111111111111111100000000e0
The error is exactly -2-44 which is -5.6843x10-14. The conversion between decimal and binary and the rounding due to finite precision have caused a small error. In some cases, you get lucky and rounding errors cancel out and you might still get the 'right' answer which is why you got what you expect for mod(1.02*100, 10), but In general, you cannot rely on this.
To use mod() correctly to test the particular digit of a number, use round() to round it to the nearest whole number and compensate for floating point error.
mod(round(5.02*100), 10) == 2
What you're encountering is a floating point error or artifact, like the commenters say. This is not a Matlab bug; it's just how floating point values work. You'd get the same results in C or Java. Floating point values are "approximate" types, so exact equality comparisons using == without some rounding or tolerance are prone to error.
>> isequal(1.02*100, 102)
ans =
1
>> isequal(5.02*100, 502)
ans =
0
It's not the case that 5.02 is the only number this happens for; several around 0 are affected. Here's an example that picks out several of them.
x = 1.02:1000.02;
ix = mod(x .* 100, 10) ~= 2;
disp(x(ix))
To understand the details of what's going on here (and in many other situations you'll encounter working with floats), have a read through the Wikipedia entry for "floating point", or my favorite article on it, "What Every Computer Scientist Should Know About Floating-Point Arithmetic". (That title is hyperbole; this article goes deep and I don't understand half of it. But it's a great resource.) This stuff is particularly relevant to Matlab because Matlab does everything in floating point by default.
I am trying to compare an array of doubles to a scalar double for equality, but equality is never recognized under certain circumstances. I suspect that this has to do with the way the double is represented (e.g., 1.0 vs 1.00), but I can't figure it out.
For instance, I have generated an array composed of thousands of double values, the last few of which at some instant in time are given by
10.6000
-11.0000
10.2000
22.6000
3.4000
If I test for equality to 10.2 (or 10.2000) by the command array==10.2 (or array=10.2000), I return an array of 0s. If I place the values shown into an array manually (e.g., array=[10.6000 -11.0000 10.2000 22.6000 3.4000]), then the command is successful (i.e., array==10.2 returns 0 0 1 0 0). Could someone please explain why the equality succeeds if I input the values manually, but fails if the array is generated in the context of a program? I am able to rectify the comparison failure by using an approximate rather than an exact comparison (e.g., (array<10.20001) & (array>10.19999)), but this seems unsatisfying.
Edit: The values in the array are generated by iterative addition or subtraction of a constant double (e.g., 0.2). The modulus of this array by 0.2 should therefore be everywhere equal to 0. In fact, the modulus of each element is equal to either 0 or 0.2, as shown below for the above sequence of numbers in the array:
mod(array,0.2)
...
0.2000
0
0.2000
0.2000
0
Again, if the values are placed in an array manually and the modulus is taken, the expected value of all 0s is obtained.
The reason is MATLAB truncated the numbers in the array to preserve only 4 digits after the decimal point when displaying,. That is, the real value of your array may be [10.600000000001, -10.99999999999, ...]. You are right, this is due to the internal representation of floating-point numbers in computer, which may cause tiny errors in the computations.
Personally I think there are two solutions, one is approximate matching like you did, while the other is to round the array up first (say, with this tool from FileExchange), and then do exact matching.
Something is probably in single precision somewhere, and double elsewhere. The binary representation of e.g. 10.2 in each is different as they terminate after a different number of bits. Thus they are different:
>> if (single(10.2) == 10.2) disp('honk'); end
>> if (single(10.2) == single(10.2)) disp('honk'); end
honk
You'll need to check for equality within some small difference:
eps = 0.001;
result = abs(array-10.2) < eps;
You can find the precision used in an array using whos:
>> whos A
Name Size Bytes Class Attributes
A 1x2 8 single
Create a MATLAB function file that will accept a modulo values (from 3 to 9; that is Z3 to Z9) and
will output the least possible value describe by the modulo conditions.
Sample Simulation:
Z = [ 3 4 5 ]; % Modulo Z3, Z4, and Z5
r = [ 2 1 4 ]; % Remainder Values
Least Possible Value is 29.
The Z inputs must be an array matrix ... where in you can type any number from 3 to 9 .... and you can type 3,4,5,6,7,8,9 in any order, in any pairings or groupings ...
The r inputs should be equal to the number of z inputs too...
the output should yield the least possible value though modulo conditions...