Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
  • 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

>>> Question

 
Ranch Hand
Posts: 156
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Why the output is -7 ??



-13 will be represented as 11110011 in 2's complement. Then >>> 1 will make it 01111001 which is +ve number (+121) Then why it is -7???

What is the thing that I am not getting.

Regards.
 
Ranch Hand
Posts: 83
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think that it is casting it to an int to do the shift, and then implicitly casting it back to a byte. If you try to compile



It complains about loss of precision from int to byte. The >>> operator must automatically promote anything it has to an int.. should look in the docs.

Check out this code:



It outputs:
-7
-7
-7
2147483641
Which is 7ffffff9
or 011111....111001

Which obeys what you would expect
[ September 06, 2004: Message edited by: Tom Tolman ]
 
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
you are absolutely right Tom.

One should remember while doing any operation on byte and short that, while doing arithmatic, shifting etc operations on them they are promoted to int and then the operations are performed.

Now in the operations like ++ the typecasting to byte/short is done implecitly but for +, -, >>, etc you have to typecast the answer explicitly if you want it in byte/short format.

so..



Hope this will clear the shifting thing also
[ September 07, 2004: Message edited by: Oneal Shaha ]
 
Ranch Hand
Posts: 522
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Before the shift operation ever occurs, 'b' is promoted to an integer.

-13 = 1111 1111 1111 1111 1111 1111 1111 0011
-13 >>> 1 = 0111 1111 1111 1111 1111 1111 1111 1001 = 2147483641

The interesting part is that the compound assignment operators include an implicit cast to the type of the left hand operand, so 2147483641 will be down casted to byte thus becoming -7 (1111 1001).
 
Bharat Roy
Ranch Hand
Posts: 156
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A big Thank You to all of you for clearing my doubt.

Regards.
 
Oneal Shaha
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just one or two posts b4 this one Peter explained that >> >>> operators work like + - and I agree on that

But this made me confused caz I am not getting what is happening in Ankur's code...
I am also not sure about my own explaination...!!!

Can Peter or anybody else explain all these things to me???

Also for another post like this please refer this link...
 
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi all iam not getting how ur are getting this result explain me a bit more clear please
 
Vicken Karaoghlanian
Ranch Hand
Posts: 522
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Selva-

Some notes to keep in mind
1) Compound operators are +=, -=, *=, /=, >>=, <<=, >>>=
2) The compound assignment operators include an implicit cast to the type of the left hand operand.
3) All operands in a bit shift are promoted to at least an int.

The statement (b>>>=1) is NOT equivalent to (b = b>>>1). The last statement will produce 'possible loss of precision' error when compiled. Why? Because 'b' is promoted to integer before the shift operation ever occurs, now that 'integer' value is assigned back to a 'byte' on which the compiler complains. To allow it to compile you must explicitly cast it to byte, like this (b = (byte) b>>>1).

However, if you apply (b >>>= 1) then there is no need for the explicit cast to 'byte', the compiler will do that on your behalf.

-13 = 1111 1111 1111 1111 1111 1111 1111 0011 // promoted to integer
-13 >>> 1 = 0111 1111 1111 1111 1111 1111 1111 1001 // The shift result on integer -13

Casting 'integer' to 'byte' will trim the first twenty bits from the right, so you'll end up with "1111 1001" which is the binary representation of -7.

Hope this helps.
 
Ranch Hand
Posts: 230
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I know it is too late, a reply. But still, I wanted to do it, because I have a question cum answer to this thread. Also, I thought, people who read old threads, might get benifitted by my reply(I hope)

My Question + Answer is : Should we go down to the level of bits. Can't we say, right shifting once means "divide by 2 once". So can I say, -13/2 is -6.5 which is -7.

Please reply. But definitely, going down to the bits is what that is needed to have a thorough understanding !
 
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Should we go down to the level of bits?



There may be some special short cuts, but for 0x0435DEAD >> 13 you will probably have to go down to bit level.

Anyway the objectives require an understanding of <<, >>, >>> for long and int operands and for negative shift values. The bit twiddling method explains all of these.
 
Bharat Roy
Ranch Hand
Posts: 156
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Whooo whooo whooo. I started this thread looong time back. Well for the SCJP 1.4 preparation, YES go to bit level details and manipulate it there. That short cut many times doesn't work.

Regards

Ankur
 
Ranch Hand
Posts: 411
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi guys,
Below is my observation when one tries to do unsigned right shift on a negative number of data type BYTE.
In general if the question is



byte b = (byte) (-a >>> b);
the final value of b can be calculated as follows
if ( a/2^b == 0 )
b = - (a/2^b);
else
b = - ( (a/2^b) + 1 );


Hope this helps to all those who are having hard time with BIT manipulation like me. Let me know if that formula fails for some case.
 
It's fun to be me, and still legal in 9 states! Wanna see my tiny ad?
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic