when we are casting to int to byte... let say byte a= (byte) 128;
in k&B book its written..that.......
code. There, 128 is the bit pattern 10000000. It takes a full 8 bits to represent 128. But because the literal 128 is an int, we actually get 32 bits, with the 128 living in the right-most (lower-order) 8 bits. So a literal 128 is actually 00000000000000000000000010000000 Take our word for it; there are 32 bits there. To narrow the 32 bits representing 128, Java simply lops off the leftmost (higher-order) 24 bits. We�re left with just the 10000000. But remember that a byte is signed, with the leftmost bit representing the sign (and not part of the value of the variable). So we end up with a negative number (the 1 that used to represent 128 now represents the negative sign bit). Remember, to find out the value of a negative number using two�s complement notation, you flip all of the bits and then add 1. Flipping the 8 zeroes give us: 01111111, and adding 1 to that gives us 10000000, or back to 128! And when we apply the sign bit, we end up with -128. You must use an explicit cast to assign 128 to a byte, and the assignment leaves you with the value -128
why the value is -128 and why not minus zero or zero because
when left with 10000000 ...here left most bit must represnt the sign bit which is negtive and rest bits represent zero
------------- any why we find two complemtn and add one to the value of binary digits to get negative value of decimal
we add one because its value is one greater then positive one because negative values starts from -1 as o is part of positive value but why we flip...all the bits...
anybody can explain ? [ May 24, 2005: Message edited by: amit taneja ]
The reason for flipping all the bits and adding one comes from the fact that if you do that, you have an efficient implementation of addition to negative numbers, and also of subtraction. Consider (using 4 bits for brevity)
7 - 1 : 0111 - 0001 of course, we can do it in our heads, but a computer has no head. But we already have adders, so it would be cheap for us if we could calculate 0111 + (-1). 0111 + 1111 = (1)0110
also notice that if you calculate the 2's complement twice, you will get the original number, for example 7: 0111 --> 1001 --> 0111
There exists also the possibilities of 1's complement and of sign and value representation (which I think you are trying to apply here) where the representation of positive and negative numbers is identical except the sign bit.
The problem with that method is that subtraction is much more difficult (requires more hardware)
Joined: Mar 14, 2003
thanx for reply
but i think this is not relevent to the answer i want
pls anybody read my post again
Joined: Dec 01, 2003
I'm not really sure what your question is. Do you understand how negative numbers are represented in 2's complement form? From the statement
here left most bit must represnt the sign bit which is negtive and rest bits represent zero
one could think that you mean -5 is represented (in 8 bits) as 10000101 since the leftmost bit is the sign bit and 101 is binary for 5 -- but -5 is represented in 2's complement as 11111011. I am just trying to make sure that you understand that first.
If you already do, then take 10000000 and add 1 to it -- then you get 10000001, which is -127 in 2's complement. It is true that the number -128 in 8 bit 2's complement is a little strange. That's why you always see that primitives are 1 number larger in the negative than in the positive direction --- signed bytes are from -128 to 127, 16 bit ints are -32768 to 32767, etc.
I have an idea about doing this kind of mind calculation without doing 1's or 2's complement stuff:
For bytes, the range is from -128 to 127. Think about a one dimension line that has -128 on the left most side, and 127 at right most side, When value is 126, there is a pointer pointing at 126, when you wanna add one to it, it moves one block right from 126 to 127, which reflect the value it currently has. Now if you further add 1 to 127, the pointer is already on the right most side. Where will it move? It moves right still, but the pointer appears on the left most side now and it points at -128, which means you got value of -128; if you add one again, now the value is 129, the pointer is at -128, and it should moves right now. Then you know the value is -127. If you wanna do substraction, the pointer moves leftward. -128 is on the left most side, so -129 move left and appears on the right most side, which has the value of 127. For -130 it moves from 127 to 126, so you will get 126.
Im not too sure if this works all the time under all situation with all types of primitive values. Hope someone rate my idea.
SCJA, SCJP5.0, SCBCD, SCWCD
Joined: Mar 14, 2003
any other info ...ranchers would like to add will me more benifitial
when left with 10000000 ...here left most bit must represnt the sign bit which is negtive...
this part is true. then you wrote
and rest bits represent zero
this is NOT correct. This is a common mis-conception about negative numbers in binary fomrat, but it is definatly not correct.
By DEFINITION, if you have a leading bit of 1, you must do some math to figure out what number it represents. we use what's called "two's complement". so, we know the value will be negative, but we want to figure out the value. to do that, take all the bits EXCEPT the sign bit. in our case, we have
Now, change every bit to it's opposite state - 1's become 0s, and 0s becoms 1s, giving us
now, add one to that, giving us
now, figure out what THAT value is using normal binary technique. this gives us 128. But we remember that sign bit said our value was negative, so our real value is -128.
You just have to accept that that is how it works. the why's are a little more complicated, but basically, it makes doing the math easier, and avoids confusion of having a positive and negative 0.
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors