When I am studying bitwise one complement operator, I see some examples on the internet:
(in short)
Example 1:
int a= 15;
int b = 27;
//15 = 0000 1111
//27 = 0001 1011
The result of ~ a is -16
//-16= 0001 0000
From: https://www.youtube.com/watch?v=qfH2Fkc1ujg
If ~ is to convert 0 to 1 and 1 to 0 , why putting 0001 0000 and the result is -16?
Example 2:
Bitwise Not or Complement operator simply means the negation of each bit of the input value. It takes only one integer and it's equivalent to the ! operator.
This operator changes each binary digit of the integer, which means all 0 become 1 and all 1 become 0. The ! operator works similarly for boolean values: it reverses boolean values from true to false and vice versa.
Now let's understand with an example how to find the complement of a decimal number.
Let's do the complement of value1 = 6:
#Test
public void givenOneInteger_whenNotOperator_thenNewDecimalNumber() {
int value1 = 6;
int result = ~value1;
assertEquals(-7, result);
}
The value in binary is:
value1 = 0000 0110
By applying the complement operator, the result will be:
0000 0110 -> 1111 1001
This is the one’s complement of the decimal number 6. And since the first (leftmost) bit is 1 in binary, it means that the sign is negative for the number that is stored.
Now, since the numbers are stored as 2’s complement, first we need to find its 2’s complement and then convert the resultant binary number into a decimal number:
1111 1001 -> 0000 0110 + 1 -> 0000 0111
Finally, 0000 0111 is 7 in decimal. Since the sign bit was 1 as mentioned above, therefore the resulting answer is:
result : -7
From: https://www.baeldung.com/java-bitwise-operators#4-bitwisecomplement-
Why are the results negative?
Thanks a lot!
"Now, since the numbers are stored as 2’s complement, first we need to find its 2’s complement..." No. You're complementing too many times. You're just computing 1111 1001's value in binary, and that's -7.
In general, it is always the case that ~x == -x - 1. You can also use that to calculate the value of negative two's complement values: -x == ~x + 1, which is why you got 7: x is -7.
Related
int i =132;
byte b =(byte)i; System.out.println(b);
Mindboggling. Why is the output -124?
In Java, an int is 32 bits. A byte is 8 bits .
Most primitive types in Java are signed, and byte, short, int, and long are encoded in two's complement. (The char type is unsigned, and the concept of a sign is not applicable to boolean.)
In this number scheme the most significant bit specifies the sign of the number. If more bits are needed, the most significant bit ("MSB") is simply copied to the new MSB.
So if you have byte 255: 11111111
and you want to represent it as an int (32 bits) you simply copy the 1 to the left 24 times.
Now, one way to read a negative two's complement number is to start with the least significant bit, move left until you find the first 1, then invert every bit afterwards. The resulting number is the positive version of that number
For example: 11111111 goes to 00000001 = -1. This is what Java will display as the value.
What you probably want to do is know the unsigned value of the byte.
You can accomplish this with a bitmask that deletes everything but the least significant 8 bits. (0xff)
So:
byte signedByte = -1;
int unsignedByte = signedByte & (0xff);
System.out.println("Signed: " + signedByte + " Unsigned: " + unsignedByte);
Would print out: "Signed: -1 Unsigned: 255"
What's actually happening here?
We are using bitwise AND to mask all of the extraneous sign bits (the 1's to the left of the least significant 8 bits.)
When an int is converted into a byte, Java chops-off the left-most 24 bits
1111111111111111111111111010101
&
0000000000000000000000001111111
=
0000000000000000000000001010101
Since the 32nd bit is now the sign bit instead of the 8th bit (and we set the sign bit to 0 which is positive), the original 8 bits from the byte are read by Java as a positive value.
132 in digits (base 10) is 1000_0100 in bits (base 2) and Java stores int in 32 bits:
0000_0000_0000_0000_0000_0000_1000_0100
Algorithm for int-to-byte is left-truncate; Algorithm for System.out.println is two's-complement (Two's-complement is if leftmost bit is 1, interpret as negative one's-complement (invert bits) minus-one.); Thus System.out.println(int-to-byte( )) is:
interpret-as( if-leftmost-bit-is-1[ negative(invert-bits(minus-one(] left-truncate(0000_0000_0000_0000_0000_0000_1000_0100) [)))] )
=interpret-as( if-leftmost-bit-is-1[ negative(invert-bits(minus-one(] 1000_0100 [)))] )
=interpret-as(negative(invert-bits(minus-one(1000_0100))))
=interpret-as(negative(invert-bits(1000_0011)))
=interpret-as(negative(0111_1100))
=interpret-as(negative(124))
=interpret-as(-124)
=-124 Tada!!!
byte in Java is signed, so it has a range -2^7 to 2^7-1 - ie, -128 to 127.
Since 132 is above 127, you end up wrapping around to 132-256=-124. That is, essentially 256 (2^8) is added or subtracted until it falls into range.
For more information, you may want to read up on two's complement.
132 is outside the range of a byte which is -128 to 127 (Byte.MIN_VALUE to Byte.MAX_VALUE)
Instead the top bit of the 8-bit value is treated as the signed which indicates it is negative in this case. So the number is 132 - 256 = -124.
here is a very mechanical method without the distracting theories:
Convert the number into binary representation (use a calculator ok?)
Only copy the rightmost 8 bits (LSB) and discard the rest.
From the result of step#2, if the leftmost bit is 0, then use a calculator to convert the number to decimal. This is your answer.
Else (if the leftmost bit is 1) your answer is negative. Leave all rightmost zeros and the first non-zero bit unchanged. And reversed the rest, that is, replace 1's by 0's and 0's by 1's. Then use a calculator to convert to decimal and append a negative sign to indicate the value is negative.
This more practical method is in accordance to the much theoretical answers above. So, those still reading those Java books saying to use modulo, this is definitely wrong since the 4 steps I outlined above is definitely not a modulo operation.
Two's complement Equation:
In Java, byte (N=8) and int (N=32) are represented by the 2s-complement shown above.
From the equation, a7 is negative for byte but positive for int.
coef: a7 a6 a5 a4 a3 a2 a1 a0
Binary: 1 0 0 0 0 1 0 0
----------------------------------------------
int: 128 + 0 + 0 + 0 + 0 + 4 + 0 + 0 = 132
byte: -128 + 0 + 0 + 0 + 0 + 4 + 0 + 0 = -124
often in books you will find the explanation of casting from int to byte as being performed by modulus division. this is not strictly correct as shown below
what actually happens is the 24 most significant bits from the binary value of the int number are discarded leaving confusion if the remaining leftmost bit is set which designates the number as negative
public class castingsample{
public static void main(String args[]){
int i;
byte y;
i = 1024;
for(i = 1024; i > 0; i-- ){
y = (byte)i;
System.out.print(i + " mod 128 = " + i%128 + " also ");
System.out.println(i + " cast to byte " + " = " + y);
}
}
}
A quick algorithm that simulates the way that it work is the following:
public int toByte(int number) {
int tmp = number & 0xff
return (tmp & 0x80) == 0 ? tmp : tmp - 256;
}
How this work ? Look to daixtr answer. A implementation of exact algorithm discribed in his answer is the following:
public static int toByte(int number) {
int tmp = number & 0xff;
if ((tmp & 0x80) == 0x80) {
int bit = 1;
int mask = 0;
for(;;) {
mask |= bit;
if ((tmp & bit) == 0) {
bit <<=1;
continue;
}
int left = tmp & (~mask);
int right = tmp & mask;
left = ~left;
left &= (~mask);
tmp = left | right;
tmp = -(tmp & 0xff);
break;
}
}
return tmp;
}
If you want to understand this mathematically, like how this works
so basically numbers b/w -128 to 127 will be written same as their decimal value, above that its (your number - 256).
eg. 132, the answer will be
132 - 256 = - 124
i.e.
256 + your answer in the number
256 + (-124) is 132
Another Example
double a = 295.04;
int b = 300;
byte c = (byte) a;
byte d = (byte) b; System.out.println(c + " " + d);
the Output will be 39 44
(295 - 256) (300 - 256)
NOTE: it won't consider numbers after the decimal.
Conceptually, repeated subtractions of 256 are made to your number, until it is in the range -128 to +127. So in your case, you start with 132, then end up with -124 in one step.
Computationally, this corresponds to extracting the 8 least significant bits from your original number. (And note that the most significant bit of these 8 becomes the sign bit.)
Note that in other languages this behaviour is not defined (e.g. C and C++).
In java int takes 4 bytes=4x8=32 bits
byte = 8 bits range=-128 to 127
converting 'int' into 'byte' is like fitting big object into small box
if sign in -ve takes 2's complement
example 1: let number be 130
step 1:130 interms of bits =1000 0010
step 2:condider 1st 7 bits and 8th bit is sign(1=-ve and =+ve)
step 3:convert 1st 7 bits to 2's compliment
000 0010
-------------
111 1101
add 1
-------------
111 1110 =126
step 4:8th bit is "1" hence the sign is -ve
step 5:byte of 130=-126
Example2: let number be 500
step 1:500 interms of bits 0001 1111 0100
step 2:consider 1st 7 bits =111 0100
step 3: the remained bits are '11' gives -ve sign
step 4: take 2's compliment
111 0100
-------------
000 1011
add 1
-------------
000 1100 =12
step 5:byte of 500=-12
example 3: number=300
300=1 0010 1100
1st 7 bits =010 1100
remaining bit is '0' sign =+ve need not take 2's compliment for +ve sign
hence 010 1100 =44
byte(300) =44
N is input number
case 1: 0<=N<=127 answer=N;
case 2: 128<=N<=256 answer=N-256
case 3: N>256
temp1=N/256;
temp2=N-temp*256;
if temp2<=127 then answer=temp2;
else if temp2>=128 then answer=temp2-256;
case 4: negative number input
do same procedure.just change the sign of the solution
This question already has answers here:
Why does the negative of Integer.MIN_VALUE give the same value? [duplicate]
(2 answers)
Why does -INT_MIN = INT_MIN in a signed, two's complement representation?
(9 answers)
Closed 5 years ago.
int a = Integer.MIN_VALUE;
int b = -a;
System.out.println("a = "+a + " | b = "+b);
Result :
a = -2147483648 | b = -2147483648
I was expecting b to be a positive number.
Changing the sign of Integer.MIN_VALUE produces an overflow; you're seeing the result of that.
If you have ever done something like this:
int a = Integer.MAX_VALUE;
a++;
System.out.println(a);
You will know that when something exceeds the data type's max value, it loops back to its min value. And when it is less than the min value, it loops back to the max value.
The same thing happens here.
Negating the min value of int would mathematically give us 2147483648, but since that is one larger than the max value. It loops back to the min value again, which is -2147483648.
Fun fact: negation is basically switching every bit from 0 to 1 and 1 to 0, then adding one. Try doing this to 10000000000000000000000000000000 which is what int's min value looks like in binary.
For the underlying binary explanation, it is because signed Integers are stored with Two's complement.
So, the most negative number in binary is 1000 0000. To inverse the sign, you flip all the bits, and add one so..
1000 0000 => 0111 1111 + 1 = 1000 0000
And you're back where you started!
As in the example above, the signed range of a Byte (8 bits) is −128 to 127, so -(-128) is 128, which is 1 over 127, so it overflows back to -128.
And as for why use Two's complement? 1 - 1 becomes 1 + (-1) or 0001 + 1111 = 0000. So by storing negative numbers in Two's complement, subtraction is done by just takes the Two's complement of the second number and just adding them together. (Which is much more efficient for the machine than adding a subtraction circuit to the the Arithmetic-Logic Unit (ALU); As it already has the bit-wise not and addition to do twos complement).
Usually when we try to assign a value to an int type which is more than the max value of int type it loopbacks again starts from min value of int, e.g.
2147483648 -will become-> -2147483648
2147483649 -will become-> -2147483647
2147483650 -will become-> -2147483646
After first statement value of a is -2147483648
And when you are doing int b = -a; usually b should have
b = -a --> -(-2147483648) --> 2147483648
But max positive value of int is 2147483647 and 2147483648 is one larger than 2147483647 it will loop back by 1 and become -2147483648.
I have this piece of code I'm going to translate into mips but I don't know what it means: A = B & C[0]
When I google ternary operator I can't find any mention of the &, just e1 ? e2 : e
What does it mean?
There's no ternary operator here. The expression is equivalent to A = (B & C[0]), that is A is assigned with the result of bitwise AND applied to B and C[0].
bitwise AND
Take a look at this: https://docs.oracle.com/javase/tutorial/java/nutsandbolts/op3.html
And look here for an example
http://www.tutorialspoint.com/java/java_bitwise_operators_examples.htm
The & here is the binary (2 inputs) operator "bitwise and".
In this case you have:
A = B & C[0];
So A will receive the results of the bit-by-bit and-ing of B and C[0].
Lets imagine that A, B and C[0] are two 32 bit integers, that have values I randomly assigned them, and lets view this operation in binary:
B = 0000 0001 0010 0100 1000 1001 1011 1111
C[0] = 1001 1110 1101 1101 1010 1010 1010 0101
A = 0000 0000 0000 0100 1000 1000 1010 0101 (the and of the two values above)
that is, A has a 1 bit only where both B and C[0] have 1 bits.
In decimal this is 19171775 & 2665327269 = 297125.
BTW, a ternary operator has 3 inputs, most common being ?:, as in R = C ? B : A.
I am working out with Java Puzzlers second puzzle.
public class Change {
public static void main(String args[]) {
System.out.println(2.00 - 1.10);
}
}
You will think the answer is 0.9. But it is not. If you workout this you will get 0.8999999. The solution given is
System.out.println(new BigDecimal("2.00").subtract(new BigDecimal("1.10")));
Now it will print 0.9. I understood why it prints 0.89999. But while
I am curiously debugging BigDecimal class, I found there are many constant values substituted in most of the places. I'll list all those below and interested to know the reason behind it.
BigDecimal.java line number 394,
while (len > 10 && Character.digit(c, 10) == 0) {
offset++;
c = in[offset];
len--;
}
Here Character.digit(c,10).
public static int digit(char ch, int radix) {
return digit((int)ch, radix);
}
Here 10 is passed as radix.
Q1. Why 10 is passed there.??
BigDecimal.java line number 732
int sign = ((valBits >> 63)==0 ? 1 : -1);
int exponent = (int) ((valBits >> 52) & 0x7ffL);
long significand = (exponent==0 ? (valBits & ((1L<<52) - 1)) << 1
: (valBits & ((1L<<52) - 1)) | (1L<<52));
exponent -= 1075;
Q2. If you look into the code in depth, you can understand what the valBits is, and I am unable to understand why rightshift is used some where?
Q3. Here also you can see there as many constants like 63, 52 are used. Why?
Q4. I can understand that the hexadecimal 0x7ffL used here will increase the speed of execution. Again why BitWise & operator is used there with the hexadecimal constant.
I hope my question is clear. Sincerely your patience is appreciated.
Q1: Of course, the radix is the base of the computation. You're are using a digit in base 10 ;)
Q4: 7ff in binary: 0111 1111 1111
If you read the explanation of the bit shift operators, Java "Bit Shifting" Tutorial? you will see that >> 63 discard the 63 first bits and keep the last one. The last bit is the sign bit (for signed types). If it is 1 then the integer is negative, hence the int sign there.
Also, you can refer to https://en.wikipedia.org/wiki/Floating_point for the definition of the floating point. The 52 is to distinguish between exponent and significand.
Q4: Of course, for the exponent, you don't want to use the 'sign' bit in it, since it's not a part of the exponent, hence the mask with 7ff. The Bitwise & 0x7ff just do that; it will only put a 0 on the first bit, and leave the other to the same state. (see the truth table of the 'AND' operator https://en.wikipedia.org/wiki/Truth_table)
Edit:
Q4 complementary: If the exponent is for example 12, then the first bit will be something like:
0000 0000 1100 ... (positive value) (ex: 1x10^12)
1000 0000 1100 ... (negative value) (ex: -1x10^12)
But: 1000 0000 1100 is 2060 decimal.
if you apply the 'mask':
1000 0000 1100 & 0111 1111 1111 -> 0000 0000 1100 (12 decimal)
AND
0000 0000 1100 & 0111 1111 1111 -> 0000 0000 1100 (12 decimal)
That's what the 0x7ff is for.
This is my code:
public class test {
public static void main(String[] args) {
byte a=(byte)127, b=2;
byte c=(byte)(a*b);
System.out.println(c);
}
}
Why is the result -2?
Because a*b will result in a temporary int variable, namely, 254, which is 1111 1110. When cast to byte, this will be handled as a signed value. The MSB is 1, so its value will be negative, and the value will be -(((inv)111 1110) + 1) = -((000 0001) + 1) = -2.
a * b is 254, so your code is:
byte c=(byte)254;
The decimal 254 is the binary 11111110, which is: -2. Why?
First of all, the number is negative since it begins with 1 (Two's complement), then:
¬ 1 1 1 1 1 1 1 0 is 0 0 0 0 0 0 0 1.
0 0 0 0 0 0 0 1
1 +
---------------
0 0 0 0 0 0 1 0
This represents 2 in decimal, but remember that the MSB is 1? So final result is -2.
Since byte is a signed type 2 * 127 is binary "11111110", which is two's complement for -2.
because byte is signed, not unsigned.
254 = FE = 1111 1110
the first '1' represent the number as a negative number.
127 in 8 bits is represented in binary like this:
01111111
Multiply by 2, and you get this:
11111110
(When you multiply by 10 in base 10, all the digits can be shifted left, to the next position. The same is naturally true when you multiply by 2 in binary)
Java uses 2's complement to represent negative numbers. Basically, the left-most bit is the sign bit (0 for +, 1 for -). To convert a positive number in a negative number, flip all the bits and add one.
Example: 00000010 = 2, flip the bits: 11111101, then add one: 11111110 = -2. This is the same as 127*2 above.
I think what you tried to ask is why overflow of a 8bits signed integer will turned to negative number for your case.
As in CPU, there is not a 8bits ALU, so 8bits will be expand to 32bits, after operation, return the lower 8bits to user.
In CPU: 0000_007F * 0000_0002 = 0000_00FE
This is a overflow for signed 8bits, but the value has been calculated already.
So returned value is FE.
For 8bits signed, FE is -2.