Thread: bitwise Absolute value?

I have a small issue that I can't seem to figure out, so I thought that I would run it by all of you.

The highest order bit in a byte has a value of 128.
From my understanding, signed numeric data types use this bit to tell the number if it is positive or negative.

In an int, there are 4 bytes, which multiplied by 8, gives you how many bits there are in an int.

well...if you shift 128 to the left by the number of bytes in an int, and subtract 1, then multiply by 8, wouldn't you have the highest order bit of an integer?
Example: ( 128 << ((sizeof(int) - 1) * 8) ) : (128 << 24)

I also tried (128 << ((sizeof(int)) * 8)) : (128 << 32)
in order to isolate the bit, just in case my reasoning was flawed.

In order to obtain the absolute value though, I took that bit, and ANDed it with the value of my int, and then XORed it, to try and obtain the absolute value....
Example:

Code:

byte value = -2;

(1000 0010)

Code:

byte highbit = (128 << ((sizeof(byte) - 1) * 8));

128 or -0

Code:

byte valueHighbit = highbit & value;

1000 0010 //value
1000 0000 //highbit
-----------------------
1000 0000 //tells us the highbit is on in the value

Code:

byte result = valueHighbit ^ value;

1000 0000 //valueHighbit;
1000 0010 //value;
------------------------------
0000 0010 //result

So as you can see, the result should be positive 2.

However, if you try this, you will see it is not...Why is this?
Why does this particular approach not work? Is it the way in which I am trying to obtain the highest bit? I can do this with various other methods, but I wanted to know why this one appears to be incorrect. Please educate me!

I have used the two's compliment method for getting the absolute value, but I wanted to try other things just so I could have a better understanding of the language, and base two math.

Now, from my understanding, the two's-compliment standard signed integer type reads
1111 1111 1111 1111 1111 1111 1111 1110
as -2.

which means:
1111 1111 1111 1111 1111 1111 1000 0000
is -128


if I apply the same logic above, using -128, rather than 128, why would it fail?

Can someone please attempt to correct my flawed logic?

New understanding is that

Code:

 (((-128 << ((sizeof(value)-1)>>3))&value)^value)

should work...

Did you even think about what you posted? A little bit? After all, (sizeof(value)-1) >>3 is guaranteed to be zero for just about any data type you care to name (unless you've got a 9-byte-or-larger data type hanging around somewhere). So you've got (-128&value)^value, which isn't going to get you what you want.

If you've grasped two's complement, then you must know that finding the negative of a number must be done either by (~x)+1 or by something that simplifies to that expression. If it doesn't simplify to that expression, then quite simply it cannot be what you want.