I want to receive the string representation of a number, 2 points after the dot.
I'm using MATLAB R2015a, and noticed that num2str function returns inconsistent results:
for 0.511 I get the required result (0.51):
num2str(0.511,2)
ans =
0.51
for 1.711 I get 1.7 instead of 1.71:
num2str(1.511,2)
ans =
1.5
Anyone knows why?
the 'precision' scalar input to num2str is the number of significant digits. if you want to have 2 figures after the decimal point use the 'formatSpec' string argument:
num2str(0.511,'%.2f')
0.51
num2str(1.511,'%.2f')
1.51
From the documentation for num2str():
s = num2str(A,precision) returns a character array that represents the numbers with the maximum number of significant digits specified by precision.
In other words, the second parameter controls the total number of significant figures, not the number of decimal places.
If you want to round to two decimal places, then use the round() function. You can try rounding the number before calling num2str():
num2str(round(1.511,2))
Related
I have a matrix of order 3 x 3, and all elements of matrix are up to 6 decimal place. I want to display this elements of matrix only up to 5 decimal place. I used format short and format long, but it gives either 4 or 15 decimal places.
Is there a command that gives up to any particular decimal places?
I have idea for a single number but could not solve for all entries of a matrix.
The builtin format options cannot handle this. You'll instead want to use fprintf or num2str (with a format specifier) to force the appearance of the number
data = rand(3) * 100;
num2str(data,'%12.5f')
% 20.42155 3.95486 91.50871
% 9.28906 87.24924 72.61826
% 47.43655 95.70325 94.41092
If you want to make this the default display at the command line you could overload the builtin display method for double but I would not recommend that.
Alternately, you can use vpa to specify the number of significant digits to display (note that the second input is the number of significant digits and not the number of numbers after the radix point).
vpa(data, 5)
I am summing numbers between two indices in a matrix, like this: ans = sum(my_matrix1x500(100:300));
The ans then is a number like: 351267300.4473 and so on. How do I prevent it from printing the decimals? Instead of 351267300.4473 it could print 3512673004473 or simply remove the decimal, is this possible?
Use fprintf('%.0f',X) to print X with '0' significant digits, or round(X) to remove the decimal altogether.
If you have an arbitrary number of decimal places this is not gonna work easily, since the number usually has many more decimal places than it shows. Read the discussion here.
But if you know how many decimal places you want to keep, you simply write:
p = 4 % number of decimal places to keep
ans = floor(ans * 10 ^ p);
This gives you the desired numerical value.
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.
These two long numbers are the same except for the last digit.
test = [];
test(1) = 33777100285870080;
test(2) = 33777100285870082;
but the last digit is lost when the numbers are put in the array:
unique(test)
ans = 3.3777e+16
How can I prevent this? The numbers are ID codes and losing the last digit is screwing everything up.
Matlab uses 64-bit floating point representation by default for numbers. Those have a base-10 16-digit precision (more or less) and your numbers seem to exceed that.
Use something like uint64 to store your numbers:
> test = [uint64(33777100285870080); uint64(33777100285870082)];
> disp(test(1));
33777100285870080
> disp(test(2));
33777100285870082
This is really a rounding error, not a display error. To get the correct strings for output purposes, use int2str, because, again, num2str uses a 64-bit floating point representation, and that has rounding errors in this case.
To add more explanation to #rubenvb's solution, your values are greater than flintmax for IEEE 754 double precision floating-point, i.e, greater than 2^53. After this point not all integers can be exactly represented as doubles. See also this related question.
I wanted to create a vector with three values 1/6, 2/3 and 1/6. Obviously I Matlab has to convert these rational numbers into real numbers but I expected that it would maximize the precision available.
It's storing the values as doubles but it's storing them as -
b =
0.1667 0.6667 0.1667
This is a huge loss of precision. Isn't double supposed to mean 52 bits of accuracy for the fractional part of the number, why are the numbers truncated so severly?
The numbers are only displayed that way. Internally, they use full precision. You can use the format command to change display precision. For example:
format long
will display them as:
0.166666666666667 0.666666666666667 0.166666666666667
So the answer is simple; there is no loss of precision. It's only a display issue.
You can read the documentation on what other formats you can use to display numbers.
you can not store values as 1/2 or 1/4 or 1/6 in to a Double variable... these are stored as decimals behind the system; if you want to store these values , try storing it as string that would work;
Whenever you want to make mathematical calculation using these strings then convert the value into number and continue....