MATLAB: How binary floating point to real decimal number representation

[matlab][math][logic]MATLAB

Hi, :

I'm sorry, if ask the wrong question, actually I don't know which domain it is, just know it's about math, logic, programming, which Matlab plays a very important part in the world.

My question is , in computer domain, there are floating point, eg: single/double precision floating point, which store variables in [sign, exponent, significand] format sized in [1, 11, 52] bits (for 64 bit precision double type) , refer to https://en.wikipedia.org/wiki/Double-precision_floating-point_format

How do those floating number stored in computer (normally, binary format) to represent in decimal (with fractional number , between 0 ~ 1), especially, those numbers been right of the '.' (radix).

For example, a floating number in binary, 1.111111 is in decimal = 1.9844, how do the computer represent the .9844 to us ? From many docs, they all say, it's ' 2^-1 + 2^-2 +…+ 2^-6', but that's not what I want to ask, it's most likely I am curious about how do the computer translate 0.5 + 0.25 + …. + 0.0156, in computer, they are binary, only 010101…, so when they do arithmetic, they are based on 0,1,0,1…, so that definitely won't really recognize the decimal, '0.5', '0.25', …,etc, but when we do those simple directives in Matlab, bin2dec(), f_b2d, it quickly gives the answers, I am interested in 'who' do those binary to 'decimal-string-output' task, in which level ? compiler ? What's the domain talking about those domain ?

Thank you very much.

Best regards.

Best Answer

Yes, as Stephen said, be careful about the difference between binary numbers and IEEE storage. You can easily see the IEEE representation of a double number in matlab with:

>> n = 1.9844
>> dec2bin(typecast(n, 'uint64'), 64);  %typecast to uint64 doesn't change the bits, so we can extract the bit pattern
ans = 
    '0011111111111111110000000001101000110110111000101110101100011100'

As for your question, the computer is never aware of the decimal representation of the number, and doesn't care about it. All math is done with the binary representation. Which is why people sometimes are surprised by the result they get (see why 0.3-0.2-0.1 is not 0) because the binary math differs from the decima math. It's only for display to the user/programmer that the numbers are converted to their textual decimal representation. This is done by well established code routine, if you want to know more search for the source code of fprintf (in C). Similarly, the textual decimal representation of numbers you enter is immediately converted to the binary representation.

Related Solutions

MATLAB: Binary floating point Representation in Matlab

Did you try it?

>> A=[ 0.1900 -0.0300 -0.1300  0  0.1500 -0.0700 0.0500  0.1600 -0.2500  -0.1900];
>> dec2bin(typecast(A,'uint64'),64)
ans =
0011111111001000010100011110101110000101000111101011100000000000
1011111110011110101110000101000111101011100001010010000000000000
1011111111000000101000111101011100001010001111010111000000000000
0000000000000000000000000000000000000000000000000000000000000000
0011111111000011001100110011001100110011001100110011010000000000
1011111110110001111010111000010100011110101110000101000000000000
0011111110101001100110011001100110011001100110011001101000000000
0011111111000100011110101110000101000111101011100001010000000000
1011111111010000000000000000000000000000000000000000000000000000
1011111111001000010100011110101110000101000111101011100000000000

MATLAB: What’s going on with the precision calculation

No. MATLAB is not getting it all wrong. The problem lies in your understanding of floating point arithmetic, and how numbers are stored.

p15 = 0.8683*1.15;
format long g
p15
p15 =
                0.998545

So, it LOOKS like the result is what you would expect. Is it? No. The issue is that floating point numbers are stored NOT in decimal form, but in binary. So, for example, 0.1 is NOT exactly representable in binary in a finite number of binary bits, just like you cannot exactly represent the fraction ⅓ in a finite number of decimal digits. As well, 0.998545 is also not exactly representable in binary.

So, the decimal representation of the number that is stored in binary for p15 is actually:

0.99854499999999990489385481851059012115001678466796875

This is the number as it is actually stored. Well, actually, it is stored in binary. But when you convert it into decimal form, you get that long mess of a decimal number.

So, how is the number 0.998545 stored as a sequence of binary bits? First, here is the repeating bit string that would represent 0.998545:

0.1111111110100000101001010010011010010101100101011111111011011010011001100001001010000011100100000100...

However, as stored in MATLAB, the binary bit used would look more like this:

0.1111111110100000101001010010011010010101100101100

As you can see, the two numbers become subtly different when you go past 50 binary bits or so.

Now, when you convert to decimal and round that result to 5 DECIMAL digits, you get 0.99854. The round goes down, because that is in fact how you should round the complete number shown above.

Welcome to the world of floating point arithmetic. As it turns out, no matter what base you store your numbers in, there will be problems like this that arise. (I believe that some calculators use a decimal form to store numbers, but there too you can contrive simple enough problems that may appear paradoxical if you do not understand how those numbers are stored and used.)

Best Answer

Related Solutions

MATLAB: Binary floating point Representation in Matlab

MATLAB: What’s going on with the precision calculation

Related Question