Hi, I am wondering if the following binary number is correct for a 64-bit computer: 1011110001​.001001110​0101011000​0001000001​1001000000​0000 or should there be 52 bits after the radix point? In my case I have 43 bits after the radix point. Thank you

Hi, I am wondering if the following binary number is correct for a 64-bit computer:

1011110001.0010011100101011000000100000110010000000000

or should there be 52 bits after the radix point? In my case I have 43 bits after the radix point.

Thank you

[James Tursa]

Correct in what sense? Compared to some fixed point scheme, or ...?

[Guillaume]

Your question is akin to asking if 1.5 is correct and should you have 3 digits instead of 1 after the radix point. We don't know the context so can't say if it is correct. As for the number of digits, you can always add more 0s if you want more digits. 1.500 is the same as 1.5, so is 1011110001.0010011100101011000000100000110010000000000b and 1011110001.0010011100101011000000100000110010000000000000000000b

edit: and they're of course both the same as 1011110001.001001110010101100000010000011001b

[H]

Basically, I wrote a code that converts decimal to binary; then, I converted a decimal number and got the following output:

753.153=1011110001.0010011100101011000000100000110010000000000

We know, for IEEE-754 representation for floats (64-bit floats double precision):

1 bit for the sign

11 bits for the exponent

52 bits for the fraction

Since it says 52 bits for the fraction whereas I only got 43 bits for the fraction! So I don’t know if my decimal to binary conversion is correct.

[James Tursa]

This is still confusing. You write about IEEE floating point formats (which have what you state but also have hidden leading bit in the mantissa), but it appears your self-converted string is a fixed point string. So which is it? What code did you write? Can you post it?

[H]

please see picture for more information

[David Goodmanson]

Hi H, To see how it works out, 'format hex' is interesting, e.g.

format hex
1/3
3fd5555555555555
-1/3
bfd5555555555555
1/2
3fe0000000000000
.1
3fb999999999999a
etc.

Answer 1

[Guillaume]

I believe I've already given you a simple piece of code to convert any number to its IEEE754 double precision representation.

dec2bin(typecast(yourdoublenumber, 'uint64'), 64)

edit: as pointed out by David, this actually doesn't work because dec2bin does some rounding. See comments below for a reliable method

the representation of 753.153 as IEEE-754 double is not what you have at all. For a start IEEE-754 doesn't use an integer.fraction encoding. The encoding is significand*base^exponent. In addition, IEEE-754 doesn't store the exponent as is, a bias is added to it. For double precision, the bias is 1023. Finally, for all numbers except denorms, the leading 1 of the significand is not stored.

753.153 in IEEE-754 is stored as roughly 1.4710019531251 * 2^(1032-1023). The 1.47... significand in binary is 1.0111100010010011100101011000000100000110001001001110b. As said, the leading 1 is not stored. The exponent 1032 in binary is 10000001000b, so 753.153 in IEEE-754 is

 0 10000001000 0111100010010011100101011000000100000110001001001110

where I've separated sign, exponant and significand (fraction) by a space.

post edited to correct some of the binary representation which was incorrectly generated by dec2bin. The gist of the post has not changed.

[H]

hi,

i need my outcome to be in the following form:

1.0111100010010011100101011000000100000110010000000000e+09 or 1011110001.0010011100101011000000100000110010000000000

using double precision (64 bit)

[H]

i did use this command

dec2bin(typecast(yourdoublenumber, 'uint64'), 64) and thereafter other commands such that I arrived at 1011110001.0010011100101011000000100000110010000000000

[David Goodmanson]

Hello Guillaume,

I don't think that that the 64 bit string in your answer is correct. Or perhaps I am missing something. I went to an online IEEE 754 calculator and also took a look at 753.153 in format hex in Matlab. (for some reason I did not include that value in my previous comment on this thread).

Everyone agrees on the leading 12 binary digits, the sign digit and the exponent:

%  0 100 0000 1000
%      4    0    8     hex

The difference is in the last 11 significand bits. In the table below, the first line is your calculation, the second two are the online calculator and the last line is Matlab hex.

0111 1000 1001 0011 1001 0101 1000 0001 0000 0110 0100 0000 0000
0111 1000 1001 0011 1001 0101 1000 0001 0000 0110 0010 0100 1110
   7    8    9    3    9    5    8    1    0    6    2    4    E
   7    8    9    3    9    5    8    1    0    6    2    4    e

[Guillaume]

Hi David,

Indeed there is a problem. I suspect that dec2bin internally convert to double and since the 64-bit representation of 753.153 is larger than flintmax you get some rounding. Interestingly, dec2hex issues a warning when that's the case, but not dec2bin (although the doc does warn you). Something to report to matlab...

Ok, here is a foolproof way of converting any double (including Nan and +/-Inf) to its binary representation:

reshape(dec2bin(bitand(idivide(typecast(number, 'uint64'), uint64(2 .^ (56:-8:0))), 255))', 1, [])

It doesn't change the fact that everything else I explained is still valid. IEEE-754 does not use integer.fraction representation, and therefore 1011110001.001001110010101100000010000011001001001110b is not IEEE-754. So if it uses less that 52 bits for the fraction it is irrelevant because the IEEE-754 fraction, as said, is 1.0111100010010011100101011000000100000110001001001110b, which is 52 bits when the initial 1 is not stored.

[H]

Hi Guillaume, Thanks for your command above using this along with my other commands I got the following:

1011110001.0010011100101011000000100000110001001001110

which is the machine number x(plus). I wanted either x(plus) or x(minus) as output (see image attached). Appreciated!

[H]

See image

[H]

Is my output:

753.153=1011110001.0010011100101011000000100000110001001001110

is now considered as double precision (for 64-bit computer)?