Show all decimal places

I am using matlab 2016b. I would like to see all decimal places of the numbers I store. For example, the input is:

x = 1.000001

then matlab returns:

x =
    1.0000

When substracting 1, matlab is showing the rest by writing

1.0000e-6

So how can I change this, so matlab displays all decimal places that are stored?

[Stephen23]

The answer that you are most likely looking for is to change the format (see KSSV's answer). But because of how values are stored as binary floating point numbers, the strict answer to your question "so matlab displays all decimal places that are stored?" is to use James Tursa's excellent FEX submission num2strexact:

https://www.mathworks.com/matlabcentral/fileexchange/22239-num2strexact--exact-version-of-num2str-

Or to simply view the complete number in hexadecimal:

https://www.mathworks.com/help/matlab/ref/num2hex.html

[Travis Briles]

Why do they do this? I don't see how this is a useful default setting...

[Walter Roberson]

Travis Briles:

Most people are really lax about the number of significant figures in their input constants. Most calculations cannot justify more than about 3 significant figures in the final answer.

[Travis Briles]

@Walter Roberson I get that but I don't get why the workspace shows many, many more decimals than the command window. Mathematica does basically the same thing but it seems much less egregious than Matlab. Cheers.

[Walter Roberson]

Preferences -> Command Window -> Text display -> Numeric format

controls the default "format" command for your session; this is which format will be used at the command window each time you start MATLAB

Preferences -> Variables -> Format -> Default array format:

controls the default "format" that is used for the Variable Browser

If I recall correctly, both of those preferences default to "short".

MATLAB computes in IEEE 754 Double Precision by default (except it does not handle NaN exactly the same as in the standard, and a couple of functions operate differently with signed zeros.) The full 53 bits of precision are available, and some people need them (or at least more than 5 decimal digits) so MATLAB gives you the option of looking at them.

Answer 1

[KSSV]

doc format. Read about format.

format long

should show what you want.

Answer 2

[Matthew Murrian]

num2str accepts precision as a second argument. If you wish to see the "exact value" of a particular floating-point value, you can use num2str with a sufficiently large value for precision. (e.g., 100 to be certain).

x = 1.000001;
num2str(x, 100)

ans = '1.0000009999999999177333620536956004798412322998046875'

You can see the next larger and smaller representable values with num2str(x + eps(x), 100) and num2str(x - eps(x), 100), respectively (not generally true for other values).

NOTE: Behavior is MATLAB version dependent. This may not work for you.

[Stephen23]

This is not a particularly reliable or repeatable approach, because different MATLAB versions and different OSs and even different HW can return different outputs.

The num2str documentation clearly states that the precision option specifies the "Maximum number of significant digits in the output string..." (emphasis added), and also has an information box that warns "If you specify precision to exceed the precision of the input floating-point data type, the results might not match the input values to the precision you specified. The result depends on your computer hardware and operating system."

You did not write what OS or version you are using, so your example has no useful context given what the documentation explains. In any case, compare:

>> num2str(1.000001,100) % R2015b Win10
ans =
1.0000009999999999

The only reliable, repeatable way to print the exact value of a floating point number is to use

https://www.mathworks.com/matlabcentral/fileexchange/22239-num2strexact--exact-version-of-num2str-

"You can see the next larger and smaller representable values with num2str(x + eps(x), 100) and num2str(x - eps(x), 100), respectively."

Strictly speaking this is incorrect. eps is defined as giving the distance "...to the next larger floating-point number" (emphasis added), and there is no equivalent to the next smaller floating point number. While most of the time these are the same, in some cases they are not. As a simple example lets consider flintmax:

>> eps(pow2(53))
ans =
     2

but the next representable value smaller than flintmax is, by the very definition of flintmax, 2^53-1, not 2^53-2.

[Walter Roberson]

Historically, sprintf() and fprintf() and num2str() [all of which use the same internal formatting code], would only display to about the 13th decimal point on Windows... and I do not mean the 15th significant digit! The digits after that would all appear as 0.

Historically, on Linux more decimal places were available than on Windows, but it was no accurate after a while.

Mac has always had exact conversion for as long as I have been using MATLAB (but I can't promise that it was always right back in the OS 9 and previous days).

The maximum width needed for exact conversion is 751:

sprintf('%.751g', eps(realmin))

'4.940656458412465441765687928682213723650598026143247644255856825006755072702087518652998363616359923797965646954457177309266567103559397963987747960107818781263007131903114045278458171678489821036887186360569987307230500063874091535649843873124733972731696151400317153853980741262385655911710266585566867681870395603106249319452715914924553293054565444011274801297099995419319894090804165633245247571478690147267801593552386115501348035264934720193790268107107491703332226844753335720832431936092382893458368060106011506169809753078342277318329247904982524730776375927247874656084778203734469699533647017972677717585125660551199131504891101451037862738167250955837389733598993664809941164205702637090279242767544565229087538682506419718265533447265625e-324'

[Matthew Murrian]

Answer updated to further clarify that MATLAB versions have inconsistent behavior. It's a convenient answer where it works.

[Matthew Murrian]

The warning "if you specify precision to exceed the precision of the input floating-point data type, the results might not match the input values to the precision you specified. The result depends on your computer hardware and operating system" is entirely consistent with my answer.

"If you specify precision to exceed the precision of the input floating-point data type": e.g., if you specify precision to exceed (about) 16 for a double.

"the results might not match the input values to the precision you specified": e.g., the results might not match 1.000001 at and beyond the specified 6 decimal places.

E.g.,

num2str(1.000001, 16) will output exactly 1.000001

num2str(1.000001, 17) may differ from 1.000001 at and beyond the 6th decimal place.

And how that result manifests at and beyond the 6th decimal place is hardware and operating system dependent.

That does not mean that my hardware and operating system is required context for this answer. If num2str does what the documentation says it does then your implementation of num2str will output results that are relevant to your hardware/OS.

And I'll note that this warning does not mention MATLAB version. If different versions of MATLAB, hardware/OS otherwise equal, produce different results from the same command without explicitly documenting that change in behavior... sloppy.

[John D'Errico]

I wonder how many confused people we will see over the years, due to an option like this. For example,

num2str(1/3,30)

ans = '0.333333333333333314829616256247'

Surely some will think that if I specified 30 digits, then why are the last 14 digits in my number incorrect?

Oh well. Just a thought.

Answer 3

[Jan]

Matlab stores floating point values in the IEE754 format, which store them as binary values. Remember that binary numbers need not have an exact decimal format with a limited number of digits, and the other way around. This is the reason for the old effect (not "problem"):

0.1 + 0.1 + 0.1 == 0.3   % FALSE!

Considering this it will be very hard to define uniquely, what "all decimal places" mean. Is 0.1+0.1+0.1 or 0.3 the "correct" answer? Neither format long g nor fprintf('.16g') will be sufficient, if you do not decide at first, what you want to consider as precision.

[Matthew Murrian]

A finite-precision value always exactly represents some real value. It just won't always exactly represent the value you'd prefer.

In the context of finite-precision values, "precision" and "all decimal places" have quite reasonable interpretations. A number expressed to "all decimal places" would, at least, show sufficient digits such that the next larger and smaller representable values (see machine epsilon) would not appear identical.

[Felipe Jiménez Hernández]

I know 0.1 (exact) is stored in the IEE754 format as a double-precision machine number as

0.100000000000000005551115123125782702118158340454101562500000000000...

because 0.1 needs infinitely many digits in base 2, and 64 digits cannot give more precision.

However if I define x = sym('0.1') with the symbolic toolbox, it should be internally represented somehow as exactly equal to 1/10. ¿How can I display x with 66 correct decimals, namely as:

0.100000000000000000000000000000000000000000000000000000000000000000

I have tried defining x = vpa('0.1', 66), but still does not show 66 correct decimals. char(a) does not work either, neither for sym('0.1') nor vpa('0.1', 66).

Thank you!

[Walter Roberson]

vpa() trims off trailing zeros.

x = vpa(1/23, 67)

x = 

0.04347826086956521739130434782608695652173913043478260869565217391304

x = vpa(1/23, 66)

x = 

0.043478260869565217391304347826086956521739130434782608695652173913

This suggests taking char() and appending as many zeros as needed to reach the target length.

[Felipe Jiménez Hernández]

But in order to know how many zeros must be added, you have to know how many digits of precision are in x. I actually expected char(x) to give me that info visually. If x is any vpa number, how do you find how many digits of precision are in x?

[Walter Roberson]

digits_target = 66;

%example number deliberately truncated small
x = vpa(1/23, 52)

x = 

0.04347826086956521739130434782608695652173913043478261

chx = char(x);
dotoffset = regexp(chx, '\.');
padding_needed = digits_target - (length(chx) - dotoffset);
chx = [chx, repmat('0', 1, padding_needed)]

chx = '0.043478260869565217391304347826086956521739130434782610000000000000'

length(chx)

ans = 68

leading 0 is 1 digit, decimal point is 1 digits, then 66 digits after = 68.