Win a copy of Building Blockchain Apps this week in the Cloud/Virtualization forum!
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
• Campbell Ritchie
• Paul Clapham
• Liutauras Vilda
• Knute Snortum
• Bear Bibeault
Sheriffs:
• Devaka Cooray
• Jeanne Boyarsky
• Junilu Lacar
Saloon Keepers:
• Ron McLeod
• Stephan van Hulst
• Tim Moores
• Carey Brown
• salvin francis
Bartenders:
• Tim Holloway
• Piet Souris
• Frits Walraven

# A doubt in bitwise operator

Ranch Hand
Posts: 57

The output of the above program is

-15
-1
15
1
-1

My doubt is
b is -1,
b1 is -15,
b4 is 1

when i do it manually

i am know i am going wrong somewhere

please clear my doubt on this
thanks
[ October 04, 2005: Message edited by: Barry Gaunt ]

Ranch Hand
Posts: 1609
Hi Jenny!
Your first step itself is wrong. I get

b as -15

a byte is 8 bits. and 0xf1 means

1111 00001

Which is -15. This thread should help...

https://coderanch.com/t/250859/java-programmer-SCJP/certification/Bitwise-Complement-Operator

And i dont get the PURPOSE of unnecessary garbage that you have put with the array of characters there.
[ October 03, 2005: Message edited by: Akhil Trivedi ]

Greenhorn
Posts: 22
Hi,

I have seen the given thread. The explanation is real good.
I am having some confusion regarding (byte)((byte)-15>>>4).

How it is giving the result -1? >>> is unsigned shift and I am calculating this shift as follows.

-15: 1111 0001
>>>4: 0000 1111

1111 is decimal 15 and is having its left most bit 0, which makes it positive. Thus I expected the answer 15.

Please clarify how it is giving -1?

Ranch Hand
Posts: 121
15 as byte : 0000 1111
-15 as byte : 1111 0001

-15 as int : 1111 1111 1111 1111 1111 1111 1111 0001
1st shift : 0111 1111 1111 1111 1111 1111 1111 1000
2nd shift : 0011 1111 1111 1111 1111 1111 1111 1100
3rd shift : 0001 1111 1111 1111 1111 1111 1111 1110
4th shift : 0000 1111 1111 1111 1111 1111 1111 1111

result as byte : 1111 1111
2's complement : 0000 0001
value: -1

NOTE:
1. When a negative byte is promoted to an int, the first 24 bits are 1's, not 0's (obviously, to maintain the sign).
2. When an int is converted to byte, the first 24 bits are truncated, irrespective of the sign!
3. Shift operations are always done on 32 bits: byte is promoted to an int and then shifted.
[ October 04, 2005: Message edited by: Sravan Kumar ]

Akhilesh Trivedi
Ranch Hand
Posts: 1609
Thank you Roja for alerting. There is much more to this example than just shifting of operators.

1. All integral numbers are integer by default.
2. Converting int to bytes actually means truncating bits.
3. Any int-or-smaller expression is automatically converted to "int"

Compile and run the following code... it should be clear.

be it b>>4
or b>>>4

it will be converted to "int" first before the shift operation is applied.

Now re-read sravan's explaination. Hope this helps.

Ranch Hand
Posts: 66
Hi,

Can anyone explain the last conversion? to get b4

b4 is obtained by right shift unsigned on b by 4

By line 1 of the code value of b is
11110001 ( this is -15)

right shift of 11110001 by 1 would give us 01111000
right shift of 11110001 by 2 would give us 00111100
right shift of 11110001 by 3 would give us 00011110
right shift of 11110001 by 4 would give us 00001111

hence the answer that I get is 0x0f as the value for b4 which is 15. Can anyone let me know why b>>>4 would give us -1?

Code reffered:

Akhilesh Trivedi
Ranch Hand
Posts: 1609
Hi Ramya!
Remember any int-or-smallerexpression would first be converted to "int".
Say you have two byte values... a and b when you add them, both "a" and "b" which are 8-btis, are converted to 32-bit (not by simply extending zeros on left but by keeping the values in tact)
here... (byte)(b>>>4)
b is -15 in bytes ok.
next is shift operation, before applying that -15 which is
1111 0001 will be converted to its equivalent 32-bits. Don't do it this way...
0000 0000 0000 0000 0000 0000 1111 0001 (because this is actually 241)

BUT do it this way,
1111 1111 1111 1111 1111 1111 1111 0001 (this is -15 in 32 bits)
Apply shift >>>4
0000 1111 1111 1111 1111 1111 1111 1111
next is (byte) cast, so truncating bits except last four
1111 1111
This is obviously -1. Hope this helps.

Ramya Iyer
Ranch Hand
Posts: 66
Great Explanation! Thanks.

 Everyone is a villain in someone else's story. Especially this devious tiny ad: Java file APIs (DOC, XLS, PDF, and many more) https://products.aspose.com/total/java