# ImplicitExplicitCast doubt

Jas Oberai

Ranch Hand

Posts: 231

posted 10 years ago

- 0

Hi Friends,

I have some doubt with this ImplicitExplicitCast thing example on javaranch journal:

Here,I don't understand how come we lose our precious sign-bit after chopping off first 24-bit.The 8th bit--won't that be our sign-bit??If this,is wrong what should be the correct answer then -7??

Thanks in Advance.

I have some doubt with this ImplicitExplicitCast thing example on javaranch journal:

Here,I don't understand how come we lose our precious sign-bit after chopping off first 24-bit.The 8th bit--won't that be our sign-bit??If this,is wrong what should be the correct answer then -7??

Thanks in Advance.

SCJP 1.4 (88%)<br />SCWCD 1.4 (88%)

Animesh Shrivastava

Ranch Hand

Posts: 298

posted 10 years ago

- 0

Jas,

I am not able to understand what u r trying to say. But this is how u calculate the final result.

After chopping off the 24 bits u get the result as:

11111001

To calculate the actual value, which is -ve ofcourse what u do is

00000110 (1's complement of the original value)

+1 (add 1 to it)

--------

00000111 (this is ur result)= 7

since, thr result has to be negative, so it comes to -7.

Hope this is clear.

If ur doubt still persists do calrify it.

I am not able to understand what u r trying to say. But this is how u calculate the final result.

After chopping off the 24 bits u get the result as:

11111001

To calculate the actual value, which is -ve ofcourse what u do is

00000110 (1's complement of the original value)

+1 (add 1 to it)

--------

00000111 (this is ur result)= 7

since, thr result has to be negative, so it comes to -7.

Hope this is clear.

If ur doubt still persists do calrify it.

Joe Sondow

Ranch Hand

Posts: 195

posted 10 years ago

- 0

The statement

b1 >>>= 1;

is a compound statement that is equivalent to

b1 = (byte)(b1 >>> 1);

The part in the parentheses shows a byte variable getting bitshifted to the

right with the unsigned right shift operator. This means that b1 will be

promoted to an int so its bit pattern will be:

11111111111111111111111111110011

which is -13.

Then it will be shifted right one place, with a leading zero added on to

the left side, because that's how >>> works:

01111111111111111111111111111001

which is positive 2147483641 because the 0 on the left end is the sign bit

for this 32-bit int value. The number is positive because the leftmost bit

is a 0.

So (b1 >>> 1) evalutes to 2147483641.

The statement can now be rewritten:

b1 = (byte)(2147483641);

The next step is to cast this value explicitly to a byte. Since its current

bit pattern is

01111111111111111111111111111001

casting it to a byte will discard the high-order 24 bits (the ones on the

left). Here's that value with x's for the bits that will be discarded:

xxxxxxxxxxxxxxxxxxxxxxxx11111001

After discarding those bits, the resulting byte has the bit pattern

11111001

which is now negative because the leftmost bit is 1. This value is -7.

The statement can now be rewritten:

b1 = -7;

If b1 had been an int or long instead of a byte, then you could assume that

the result of

b1 >>>= 1;

would be positive, since >>> puts a zero on the left. However,

because of the cast to byte, there's no certainty that the result will be

positive or negative until you work through the problem, since the sign bit

of the int gets discarded, and whatever bit happens to be in the 8th place

from the right will be the sign bit of the byte that results from the cast

to byte. In this case that bit is a 1, so the byte is negative.

[ May 05, 2005: Message edited by: Joe Sanowitz ]

[ May 05, 2005: Message edited by: Joe Sanowitz ]

b1 >>>= 1;

is a compound statement that is equivalent to

b1 = (byte)(b1 >>> 1);

The part in the parentheses shows a byte variable getting bitshifted to the

right with the unsigned right shift operator. This means that b1 will be

promoted to an int so its bit pattern will be:

11111111111111111111111111110011

which is -13.

Then it will be shifted right one place, with a leading zero added on to

the left side, because that's how >>> works:

01111111111111111111111111111001

which is positive 2147483641 because the 0 on the left end is the sign bit

for this 32-bit int value. The number is positive because the leftmost bit

is a 0.

So (b1 >>> 1) evalutes to 2147483641.

The statement can now be rewritten:

b1 = (byte)(2147483641);

The next step is to cast this value explicitly to a byte. Since its current

bit pattern is

01111111111111111111111111111001

casting it to a byte will discard the high-order 24 bits (the ones on the

left). Here's that value with x's for the bits that will be discarded:

xxxxxxxxxxxxxxxxxxxxxxxx11111001

After discarding those bits, the resulting byte has the bit pattern

11111001

which is now negative because the leftmost bit is 1. This value is -7.

The statement can now be rewritten:

b1 = -7;

If b1 had been an int or long instead of a byte, then you could assume that

the result of

b1 >>>= 1;

would be positive, since >>> puts a zero on the left. However,

because of the cast to byte, there's no certainty that the result will be

positive or negative until you work through the problem, since the sign bit

of the int gets discarded, and whatever bit happens to be in the 8th place

from the right will be the sign bit of the byte that results from the cast

to byte. In this case that bit is a 1, so the byte is negative.

[ May 05, 2005: Message edited by: Joe Sanowitz ]

[ May 05, 2005: Message edited by: Joe Sanowitz ]

SCJA 1.0 (98%), SCJP 1.4 (98%)

Jas Oberai

Ranch Hand

Posts: 231

posted 10 years ago

- 0

Thanks Animesh and Joe,

Animesh i am trying to understand what Joe is trying to explain to me.Thanks Joe,after reading your post all my doubts got cleared....the only mistake i was making was i was taking the "unsigned right shift operator"...as a "signed right shift operator"..and then wondering what the author is tryin to prove.

Anywas,thanks for your help!!!

Animesh i am trying to understand what Joe is trying to explain to me.Thanks Joe,after reading your post all my doubts got cleared....the only mistake i was making was i was taking the "unsigned right shift operator"...as a "signed right shift operator"..and then wondering what the author is tryin to prove.

Anywas,thanks for your help!!!

SCJP 1.4 (88%)<br />SCWCD 1.4 (88%)

I agree. Here's the link: http://aspose.com/file-tools |