# confusion in casting..

amit taneja

Ranch Hand

Posts: 813

posted 10 years ago

- 0

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

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 ]

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 ]

Thanks and Regards, Amit Taneja

Timmy Marks

Ranch Hand

Posts: 226

posted 10 years ago

- 0

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)

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

Posts: 813

Timmy Marks

Ranch Hand

Posts: 226

posted 10 years ago

- 0

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

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.

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

Posts: 287

posted 10 years ago

- 0

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.

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

amit taneja

Ranch Hand

Posts: 813

posted 10 years ago

- 0

Amit, you wrote :

this part is true. then you wrote

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.

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

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

Did you see how Paul cut 87% off of his electric heat bill with 82 watts of micro heaters? |