Bit Stuffing

I have three numbers that I'm limiting to 10 bits each and then hoping to packing into a 32-bit standard int.  This would be easy if the numbers were just positive, but they also could be negative.  I end up fighting with the 2s complement.  I know someone is going to suggest just saving myself some headache and forcing the last bit to represent a truncated positive/negative flag, but I really need all ten of those bits for the number (anyone have a 33-bit data type they can spare?).

Now I've already looked online and there isn't much to digest about the matter.  Of the two lonely solutions I've found, one doesn't seem to work and the other is a hassle to implement.  Knowing what I do about 2s complement I'm inclined to believe the latter is the case - it's a hassle no matter what - but I'm also stubborn enough to be believe that there is a more elegant solution.

Presuming num_unpacked is a 32-bit int with one of the 10-bit numbers from some num_packed in its lowest 10 bits:
num_unpacked |= (~0 * ((1<<9) & num_unpacked));
i.e., if the highest bit of the 10bit number means it's negative, make the 'unused' bits 1 to make it negative.

So what's the question?

>>2
There was other code before that that I deleted, but hopefully it makes sense.

Looks like op can not into 2-complement

>>1
Unless it's a hard requirement you're wasting your time by trying to pack them all.

For fun: does order of the numbers have to be maintained? If not you can encode all the information by reordering the numbers, encoding sign information in the extra two bits.

>>1
By 10-bit numbers, you mean that they can go from -512 to 511, right?

Am I the only one who thinks this is impossible?

Two bits only have 2^2 probabilities: 00, 01, 10 and 11.

Three numbers have 2^3 probabilities: +++, ++-, +-+, +--, -++, -+-, --+ and ---.

In other words, it's logically impossible to implement such a thing in two bits.

>1-1000 Fuck you, ``Faggot''.

>>9 You fail, ``Sussmangot''.

>>7
I was asking /prog/ in hopes that I could squeeze as much value into (and out of) those ten bits as possible; if there was a way, surely there was a madman who had figured it out.  511 to -512 does seem to be the best I can do.

>>2
I was moving in that direction at one point.

I'm >>8. Nobody answered me! ;-;

>>12
Some of us presumed the question was rhetorical.

>>11
You can't fit more than 32 bits of entropy in a 32-bit word. You cannot fit three times 11 bits of entropy (1 bit sign, 10 bits mantissa 0..1023) as that would amount to 33 bits of entropy, which is larger than the word size in this case. The best you can do is 10 bits of entropy (1 bit sign, 9 bits mantissa 0..511). And yes, you should use two's complement.

I managed to chain together a bunch of bitwise that works for both positive and negative numbers nine bits long, plus a sign.
int x = -411;
int packed_bits = x&1024 | x&1023;
and
int y = packed_bits&1023;
x = (y&512)>0 ? -(~y&511)-1 : y&511;
That sound is me glaring at the ternary.

>>14
Now you're making me think about that infinite compression scam.

>>15
surely though, if you're going for 9 bits a piece, then you don't have to "compress" them.