• Post Reply Bookmark Topic Watch Topic
  • New Topic
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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

bit shift operators

 
Ranch Hand
Posts: 305
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Greetings Friends,

A question about bit shift operators. Assume I have the following:

int x = -8; //binary = 1000 0000 0000 0000 0000 0000 0000 1000

Now, if I perform the following operation:

x >>= 2;

I get a result of -2. However, I must be misunderstanding the dynamics of the >> operator. Doesn't it shift the sign bit to the right, keeping the original sign bit value in its place and replacing each bit to the right with the value of the sign bit? So the final binary representation should be the large (well, small really) negative number:

1110 0000 0000 0000 0000 0000 0000 0010

But it seems the >> operator, while preserving the sign bit, only shifts the bit in the 4th position (not the sign bit itself), resulting in -2.

Can anyone explain the actions of the >> operator further? Thanks for your attention,

J
 
Ranch Hand
Posts: 539
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yours and my understanding of >> is the same (I'm not saying we're correct ), but I think your confusion is caused by how Java represents ints: with two's complement notation.

A very very brief intro: If you have a positive bit pattern say, 0000 1010 (int +ten, in 8-bit two's complement), you get its corresponding negative by flipping the bits and adding one. So, in this case we flip the bits to '1111 0101', and add one to get '1111 0110'. That last pattern is -ve ten, in two's complement.

In any case, you can Google for a better explanation or just play around with it yourself:



Yields:





--Tim
 
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


int x = -8; //binary = 1000 0000 0000 0000 0000 0000 0000 1000



This is incorrect.
Java uses "two's complement" for representation of integral types.
I suspect this mistake voids the remainder of your explanation.
 
Jeffrey Hunter
Ranch Hand
Posts: 305
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks, guys. This clears it up (and Tim, haha, I was wondering how to print the binary representation--alas, toBinaryString()!).

Thanks.
 
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Out of curiousity, does anyone know why Sun elected to use twos complement rather than the more normal ones complement?
 
Tim West
Ranch Hand
Posts: 539
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Is one's complement more normal???

I thought 2C made everything easier: you do addition as "normal" (with unsigned binary ints), and everything just falls out correctly. This, I thought, was its major benefit over 1C.

I certainly had the impression 2C was in common use just about everywhere...am I grossly misinformed?!


--Tim
reply
    Bookmark Topic Watch Topic
  • New Topic