Negative floating point to binary conversion

Question

I am using the AR Drone SDK to program the drone. In the docs, is says this:

The number -0.8 is stored in memory as a 32- bit word whose value is BF4CCCCD(16), according to the IEEE-754 format. This 32-bit word can be considered as holding the 32-bit integer value -1085485875(10). So the command to send will be AT*PCMD=xx,xx,-1085485875,xx,xx.

How are they arriving at -1085485875 for the decimal representation of the binary conversion? It doesnt make sense to me. Using this page: http://kipirvine.com/asm/workbook/floating_tut.htm and this page: http://www.madirish.net/240 and this page http://cs.furman.edu/digitaldomain/more/ch6/dec_frac_to_bin.htm , this is what I came up with:

decimal value = -0.8

binary value of decimal (-0.8) = -.11001100110011001100110

biased exponent (move above decimal over once to right) = 127 - 1 = 126 = 01111110

sign, exponent, mantissa (mantissa: drop off the 1 to left of decimal point, pad to 23) = 1 01111110 10011001100110011001100

10111111010011001100110011001100 = 3209481420 (10) BF4CCCCC (16).

The docs says its -1085485875 (10) and BF4CCCCD (16)

What am I doing wrong here???

Thanks.

Edit:

Since I am writing an AR DRONE application with node/js, if I use these node.js functions:

var buffer = new Buffer(4);
buffer.writeFloatBE(-0.8, 0);
return -~parseInt(buffer.toString('hex'), 16) - 1;

I get the correct result as per the documentation. I just don't get what I am doing wrong when I write it out long hand. I want to understand what is going on. Any help is really appreciated.

Thanks.

UPDATE:

So, I've figured out (from the above javascript code) if I apply the bitwise NOT operator to binary first, it then produces the correct number. My question is, why does this need to be applied? After doing this, you'll have to determine if its negative if the first bit is a zero not a one. Whats the point of this?

Try rounding the mantissa instead of just truncating it and also try interpreting the result as a two's complement number. — Bovinedragon, Nov 18 '12 at 01:22
@Bovinedragon I don't understand when you say I am truncating the mantissa, where am I doing this? Could you give me a little more information about interpreting the result as a two's complement number? The .8 becomes a repeating binary pattern of 1100, so I repeat it to 22 places, but then since I remove 1 off the left of decimal, I then pad it with another 0 at the end. Where am I truncating it though? I just take the sign, the exponent, and mantissa together together, that is the final result correct? as far as how these numbers are stored in memory right? — Ian Herbert, Nov 18 '12 at 01:55
I just don't understand where they get the -1085485875 from all of this. — Ian Herbert, Nov 18 '12 at 02:00
Two's complement is a binary format that computers usually use to store integer numbers. You can probably find some resources online that can explain how it works better than I can. You are on the right track by looking at the bitwise not of the number. — Bovinedragon, Nov 18 '12 at 02:16
As for the rounding, the next few digits after the mantissa you got would be 1100, so the mantissa should be rounded up to 10011001100110011001101. — Bovinedragon, Nov 18 '12 at 02:21

score 0 · Accepted Answer · answered Nov 18 '12 at 04:50

-0.8 = -0.110011001100110011001100 11001100110011001100110011001100110011... (the space is between bits 24 and 25 -- bit 25 is the rounding bit). This rounds to 24 bits as 0.110011001100110011001101. Here's how it looks in IEEE single-precision format:

sign  biased exponent    trailing 23-bits of mantissa
 \/        \/                      \/
 1      01111110         10011001100110011001101

That's 10111111010011001100110011001101, or BF4CCCCD in hex. If you view that as a twos-complement an integer, it's -1085485875.

Negative floating point to binary conversion

1 Answers1