File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes confusion in casting.. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "confusion in casting.." Watch "confusion in casting.." New topic

confusion in casting..

amit taneja
Ranch Hand

Joined: Mar 14, 2003
Posts: 812
hi i have bit confusion in cast in k&B..

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
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 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 ]

Thanks and Regards, Amit Taneja
Timmy Marks
Ranch Hand

Joined: Dec 01, 2003
Posts: 226
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)
amit taneja
Ranch Hand

Joined: Mar 14, 2003
Posts: 812
thanx for reply

but i think this is not relevent to the answer i want

pls anybody read my post again

Timmy Marks
Ranch Hand

Joined: Dec 01, 2003
Posts: 226
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.
reubin haz
Ranch Hand

Joined: May 12, 2005
Posts: 287
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.

amit taneja
Ranch Hand

Joined: Mar 14, 2003
Posts: 812
any other info ...ranchers would like to add will me more benifitial

fred rosenberger
lowercase baba

Joined: Oct 02, 2003
Posts: 11951

Amit, you wrote :
when left with 10000000 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

000 0000

Now, change every bit to it's opposite state - 1's become 0s, and 0s becoms 1s, giving us

111 1111

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
I agree. Here's the link:
subject: confusion in casting..
It's not a secret anymore!