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.
Related
I have a set of integer values, for example:
V = [26767559, 6022443, 9923637]; % etc.
For my application, it is convenient to represent them as <rounded_mantissa>E5 (that is, some_val*105), so for the above examples I want to get:
N = ["268E5", "60E5", "99E5"]; % I won't mind if it's E+05
At the moment, I'm using one of several conceivable workarounds to achieve this output,
N = round(V*1E-5) + "E5";
but I'd like to know if it's possible to specify the formatSpec of sprintf, num2str (etc.) such that it would output numbers with a specific value for the exponent (in this case, 5), without performing division (like in num2str(round(V/1E5).','%3uE5')).
I'm using R2018a.
You can at least remove the use of round, then I don't think there's any further short-hand because it's just a single division...
N = num2str( V/1e5, '%.0fE5' )
The .0 precision operator will force the 0 decimal place rounding for you anyway.
You can only specify the number of digits (significant or after the decimal point) using the formatSpec property, so unless you've got fixed numbers of digits (which you don't) you won't be able to use that alone.
Let's say I create some number A, of the order 10^4:
A = 81472.368639;
disp(A)
8.1472e+04
That wasn't what I wanted. Where are my decimals? There should be six decimals more. Checking the variable editor shows me this:
Again, I lost my decimals. How do I keep these for further calculations?
Scientific notation, or why you didn't lose any decimals
You didn't lose any decimals, this is just MATLAB's way of displaying large numbers. MATLAB rounds the display of numbers, both in the command window and in the variable editor, to one digit before the dot and four after that, using scientific notation. Scientific notation is the Xe+y notation, where X is some number, and y an integer. This means X times 10 to the power of y, which can be visualised as "shift the dot to the right for y places" (or to the left if y is negative).
Force MATLAB to show you all your decimals
Now that we know what MATLAB does, can we force it to show us our number? Of course, there're several options for that, the easiest is setting a longer format. The most used for displaying long numbers are format long and format longG, whose difference is apparent when we use them:
format long
A
A =
8.1472368639e+04
format longG
A
A =
81472.368639
format long displays all decimals (up to 16 total) using scientific notation, format longG tries to display numbers without scientific notation but with most available decimals, again: as many as there are or up to 16 digits, both before and after the dot, in total.
A more fancy solution is using disp(sprintf()) or fprintf if you want an exact number of decimals before the dot, after the dot, or both:
fprintf('A = %5.3f\n',A) % \n is just to force a line break
A = 81472.369
disp(sprintf('A = %5.2f\n',A))
A = 81472.37
Finally, remember the variable editor? How do we get that to show our variable completely? Simple: click on the cell containing the number:
So, in short: we didn't lose any decimals along the way, MATLAB still stores them internally, it just displays less decimals by default.
Other uses of format
format has another nice property in that you can set format compact, which gets rid of all the additional empty lines which MATLAB normally adds in the command window:
format compact
format long
A
A =
8.147236863931789e+04
format longG
A
A =
81472.3686393179
which in my opinion is very handy when you don't want to make your command window very big, but don't want to scroll a lot either.
format shortG and format longG are useful when your array has very different numbers in them:
b = 10.^(-3:3);
A.*b
ans =
1.0e+07 *
0.0000 0.0001 0.0008 0.0081 0.0815 0.8147 8.1472
format longG
A.*b
ans =
Columns 1 through 3
81.472368639 814.72368639 8147.2368639
Columns 4 through 6
81472.368639 814723.68639 8147236.8639
Column 7
81472368.639
format shortG
A.*b
ans =
81.472 814.72 8147.2 81472 8.1472e+05 8.1472e+06 8.1472e+07
i.e. they work like long and short on single numbers, but chooses the most convenient display format for each of the numbers.
There's a few more exotic options, like shortE, shortEng, hex etc, but those you can find well documented in The MathWork's own documentation on format.
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))
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'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.