When I give to a variable such value: e = 17|-15; , I get -15 as an answer after compiling.I can't understand what arithmetic c++ uses. How does it perform a bit-wise OR operation on negative decimals?
It's just doing the operation on the binary representations of your numbers. In your case, that appears to be two's complement.
17 -> 00010001
-15 -> 11110001
As you can see, the bitwise OR of those two numbers is still -15.
In your comments above, you indicated that you tried this with the two's complement representations, but you must have done something wrong. Here's the step by step:
15 -> 00001111 // 15 decimal is 00001111 binary
-15 -> ~00001111 + 1 // negation in two's complement is equvalent to ~x + 1
-15 -> 11110000 + 1 // do the complement
-15 -> 11110001 // add the 1
It does OR operations on negative numbers the same way it does so on positive numbers. The numbers are almost certainly represented in two's-complement form, which gives you these values:
17 = 0000000000010001
-15 = 1111111111110001
As you can see, all the bits of 17 are already set in −15, so the result of combining them is again −15.
A bitwise or with a negative number works JUST like a bitwise or with a positive number. The bits in one number are ored with the bits in the other number. How your processor represents negative numbers is a different matter. Most use something called "two's complement", which is essentially "invert the number and add 1".
So, if we have, for simplicity, 8 bit numbers:
15 is 00001111
Inverted we get 11110000
Add one 11110001
17 is 00010001
Ored together 11110001
17 = b00010001
-15 = b11110001 <--- 2s complement
| -15 = b11110001
The operator | is a "bitwise OR" operator, meaning that every bit in the target is computed as the OR-combination of the corresponding bits in the two operands. This means, that a bit in the result is 1 if any of the two bits in the numbers at the same positions are 1, otherwise 0.
Clearly, the result depends on the binary representation of the numbers which again depends on the platform.
Almost all platforms use the Two's complement, which can be thought as a circle of unsigned numbers, in which negative numbers are just in the opposite direction than positive numbers and "wrap around" the circle.
Unsigned integers:
Signed integers:
The calculation of your example is as follows.
17: 00000000 00000000 00000000 00010001
-15: 11111111 11111111 11111111 11110001
------------------------------------------
-15: 11111111 11111111 11111111 11110001
you have to looks at how the bits work
Basically, if either number has a 1 in a particular spot, than the result will also have a 1
-15 : 11110001 (two's complement)
17 : 00010001
-15 | 17 : 11110001
as you can see, the result is the same as -15
Related
This question already has answers here:
What is “two's complement”?
(24 answers)
Closed 1 year ago.
I am really curious and confused:
how is 0xFFFF (0b11111111111111) or 0xFF (0b11111111) -1?
if 0b01111111 is 127 and the first bit indicates that it is a positive number then shouldn't 0b11111111 be -127?
Am I missing something???
Two's complement form is commonly used to represent signed integers. To swap the sign of a number this way, invert all the bits and add 1. It has the advantage that there is only one representation of zero.
01111111 = 127
To get -127 flip the bits:
10000000
And add 1:
10000001
To negate 1:
00000001
11111110 // flip
11111111 // + 1
With 0:
00000000
11111111 // flip
00000000 // + 1 (the carry bit is discarded and it's still 0)
And just to show it works going the other way:
With -127:
10000001
01111110 // flip
01111111 // + 1 and you are back to +127.
If we use seven-bit two's complement binary representation for integers, what is
The number of integers (things) that can be represented in this way?
The smallest (most) negative integer that can be represented in this way?
The largest positive integer that can be represented in this way?
This is a CS homework question that I am having trouble answering and explaining. Any help would be appreciated.
So its really easy
Counting in binary usually goes like
>00000000 (8) = 0
>00000001 (8) = 1
>00000010 (8) = 2
>00000011 (8) = 3
>etc...etc.
In 7 bit the last bit is what decides if its a negative or positive
1 being negative and 0 being positive
> 10000000 = -128
> 10000001 = -127
> 10000010 = -126
> On...and on...
> 11111111 = -1
> 00000000 = 0
> 00000001 = 1
> 01111111 = 127
So lowest you can go is -128
Highest you can go is 127
Approved answer is not correct.
With 7-bits of 2's complement, it could range from -64 to 63. (traditionally, 7 bits can only go up to 2^n-1 which is 128 but MSB is reserved for sign, so we could have 6 bits to represent the data.
We will be getting 64 positive and 63 negative values and answer should be -64, 63.)
No, because in two's complement, the most significant bit is the sign bit. 0000001 is +1, a positive number.
That is why the range of two's complement 7-bit numbers is -64 to 63, because 64 is not representable (it would be negative number otherwise).
The most negative number is 1000000. The leading 1 tells you it's negative, and to get the magnitude of the number, you flip all the bits (0111111), then add one (1000000 = 64). So the resulting number is -64 thru 63.
For largest positive integer in 2's complement use the formula
(2^(n-1)-1)
That is (2^(7-1)-1)=63
For the smallest use
-2^n-1
That is -2^7-1=-64
I have some real data. For example +2 and -3. These data are represented in two's complement fixed point with 4 bit binary value where MSB represents the sign bit and number of fractional bit is zero.
So +2 = 0010
-3 = 1101
addition of this two numbers is (+2) + (-3)=-1
(0010)+(1101)=(1111)
But in case of subtraction (+2)-(-3) what should i do?
Is it needed to take the two's complement of 1101 (-3) again and add with 0010?
You can evaluate -(-3) in binary and than simply sums it with the other values.
With two's complement, evaluate the opposite of a number is pretty simple: just apply the NOT binary operation to every digits except for the less significant bit. The equation below uses the tilde to rapresent the NOT operation of a single bit and assumed to deal with integer rapresented by n bits (n = 4 in your example):
In your example (with an informal notation): -(-3) = -(1101) = 0011
This question already has answers here:
bit-wise operation unary ~ (invert)
(5 answers)
Closed 7 years ago.
int x=10;
cout<<~x;
this code prints -11. if it was simple inversion then for 00001010 the bits should be 11110101, which on conversion to decimal is -117. I have tried searching but no luck pls tell what is happening here?
I am using mingw compiler, if its of any help.
That is working as expected. "11110101" is -11 in two's complement.
As a side note, "int" is either 16 or 32 bits, so you're actually talking about
"00000000 00001010" or "00000000 00000000 00000000 00001010" respectively.
~x is equal to −x − 1. Therefore, ~10 = -10 - 1 = -11.
Using 1-byte , 10 is represented as 0000 1010. Its bit-wise NOT is 1111 0101. Generally computer represents signed integers in 2's complement format. So, decimal equivalent of 1111 0101 is -11, How?
An N-bit number w represented in 2's complement as aN-1aN-2....a0 can be converted to decimal as
Therefore,
1111 01012 = -1*27 1*26 + 1*25 + 1*24 + 0*23 + 1*22 + 0*21 + 1*20 = -128 + 117 = -11
The ~ operator works as you think it does. It's just negative numbers don't work how you think they do. Negative numbers are encoded as a two's complement http://en.wikipedia.org/wiki/Two%27s_complement
Basically, the value of the highest bit is subtracted from the value of the lower bits.
I am trying to take one's complement of 0 to get 1 but I get 4294967295. Here is what I have done:
unsigned int x = 0;
unsigned int y= ~x;
cout << y;
My output is 4294967295 but I expect 1, why is this so? By the way, I am doing this in C++.
Why do you expect 1? Bit-wise complement flips all the bits.
00000000000000000000000000000000 = 0
|
bitwise NOT
|
v
11111111111111111111111111111111 = 4294967295
Perhaps you are thinking of a logical NOT. In C++ this is written as !x.
You have to look at this in binary to understand exactly what is happening.
unsigned int x = 0, is 00000000 00000000 00000000 00000000 in memory.
The ~x statement flips all bits, meaning the above turns into:
11111111 11111111 11111111 11111111
which converts to 4294967295 in decimal form.
XOR will allow you flip only certain bits. If you only want to flip the least significant bit, use x ^ 1 instead.
Where did you get the expectation of 1 from?
Your understanding of bitwise operations clearly shows is lacking, it would be prudent to work through them first before posting in here...
you're not confusing with a ! which is a logical NOT, are you?
a ~ bitwise complement or a bitwise NOT operation flips all the bits from 1 to 0 and vice versa depending on where in the bitmask is set, so for example, a 1 is
00000000 00000000 00000000 00000001
doing a ~ bitwise NOT on that flips it to
11111111 11111111 11111111 11111110
which gives you the maximum value less 1 of the integer datatype on a 32bit system.
Here is a worthy linky to this which shows you how to do bit-twiddling here.
An integer is more than just 1 bit (it's 4 bytes, or 32 bits). By notting it, you'r flipping everything, so in this case 00000... becomes 11111...
~ flips all of the bits in the input. Your input is an unsigned int, which has 32 bits, all of which are 0. Flipping each of those 0-bits gives you 32 1-bits instead, which is binary for that large number.
If you only want to flip the least significant bit, you can use y = x ^ 1 - that is, use XOR instead.
You can use
unsigned int y= !x;
to get y = 1;