Why does num2str of a single output up to 17 digits?

I've noticed the calling num2str using a single but asking for up to 20 digits produces a lot more digits than should be stored with a single. These digits are not visible in the workspace but they are persistent; they are passed between functions and can be consistently recreated if you call the double function on the single. They do not represent the lost digits from the initial conversion to single, but running this script multiple times produces the same digits, even on different machines and versions.

What is really going on here? Is matlab really keeping track and moving these digits around, or are they somehow a function of the single precision number that is stored?

format long g
y=1.234567890123456789 %only stores 1.23456789012346
x=single(y) %only stores 1.234568 
num2str(x,20) %displays 1.2345678806304932
z=double(x); %stores 1.2345678806304932
num2str(z,20) %displays 1.2345678806304932

Answer 1

[James Tursa]

Point #1:

The behavior of num2str is platform specific. On Windows machines (at least the ones I have used), num2str will truncate the display to the underlying accuracy of the number and pad 0's on the end if you request "too many" digits. On other platforms (I believe linux is one) you will get an exact conversion of the binary floating point bit pattern into decimal for as many digits as you request.

Point #2:

On those platforms that do print many more digits than 7 or 8, num2str is simply doing the exact binary floating point bit pattern conversion into decimal with no implied precision for those remaining digits in the sense you are talking about. Nothing "extra" is being passed around or retained in memory between function calls etc. It is always only a 32-bit floating point number. E.g., compare num2str(1) and num2str(1+eps). Those numbers are right next to each other in the IEEE double representation of floating point numbers. There is nothing inbetween them in this system. To see that try num2str(1+eps/2) and see what you get. A similar situation exists for the single precision numbers.

If you are on a computer that does not do the full conversion (e.g. Windows) you can use my num2strexact utility function from the FEX:

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

[Jeremy]

The binary conversion makes sense. The memory argument doesn't hold because that script was generating the exact same results between different machines, and I could pass these variables between functions and come up with the same "garbage".

thanks.

Answer 2

[Daniel Shub]

There is a difference between stores and displays.

format long g
y = 1.234567890123456789
y = 
        1.23456789012346

x = 1.23456789012346
x =
        1.23456789012346

y == x
ans =
   0

So while the long g format display makes the numbers look the say, they are not.

[José-Luis]

I still think the OP has a point, I think this is about memory not being overwritten.

Answer 3

[José-Luis]

If you try:

 a=single(1.122658646554312321654643513232464651);
 num2str(a,20);

This will produce

 1.1226586103439331055

Meaning that you get garbage after the 9th decimal, as you should. The way you do it

y=1.234567890123456789 %only stores 1.23456789012346
x=single(y) %only stores 1.234568 
num2str(x,20) %displays 1.2345678806304932

You don't get garbage after some point. My guess is that until the memory is overwritten, the remaining digits are conserved. Try this instead to make sure the memory is overwritten (or try to move your values to another location):

format long g
y=1.234567890123456789 %only stores 1.23456789012346
x=single(y) %only stores 1.234568
bla = x + 25;
bla = bla -25;
num2str(bla,20)

 bla = 

 1.2345676422119140625

Then you get garbage. My point is that should not count on that behavior.

[Daniel Shub]

No. A single precision number floating point number has way more than 9 decimals of accuracy. In fact it has up to 45 decimals of accuracy. Consider the difference between

isequal(single(0), single(1e-46)) % true

and

isequal(single(0), single(1e-45)) % false

Working from your example consider

isequal(single(1.234567890123456789), single(1.234567890123456789)+25-25)

It has nothing to do with memory being overwritten, but rather floating point representation.

[José-Luis]

"A single precision has way more than 9 decimals of accuracy".

That would depend.

A single precision number has 23 bits of significant digits in binary. That is 8 significant digits in decimal. But we are not talking about accuracy here. The OP is storing more significant digits than a single precision float would allow, after transforming from double. I still think it is a case of overwriting memory.

 isequal(single(1.234567890123456789), single(1.234567890123456789)+25-25)

doesn't work because you are converting to double. And then you bump one of the significant numbers out when adding 25. This on the other hand works:

 isequal(single(1.234567890123456789), single(1.234567890123456789)+single(1)-single(1))

[James Tursa]

@Daniel: You are confusing precision (accuracy) with range. A single only has 7-9 digits of precision (accuracy).

[James Tursa]

@José-Luis: It is not a case of overwriting memory. See explanation in my Answer.