left shift

[devnew]

hi
i am relatively new to python..was checking out some bit shifting..
when i do
255<< 24 i get 4278190080

whereas in java or c it gives -16777216

can someone tell me why this is ?,what should i do if i want the
output as -16777216 ?

dn


p:s
I wrote a fn to show the binary digits in the number and it gives same
output for both numbers(4278190080 and -16777216)
def pBinInt(str,i):
print str,",int",i,", binary:"
print " ",
for j in range(31,-1,-1):
if(((1 << j) & i) != 0):
print 1,
else:
print 0,
print ""

#example usage pBinInt("255",255)

 

[Daniel Dyer]

hi
i am relatively new to python..was checking out some bit shifting..
when i do
255<< 24 i get 4278190080

whereas in java or c it gives -16777216

can someone tell me why this is ?,what should i do if i want the
output as -16777216 ?

Because you are using a 32-bit int and in Java all ints are signed (the
most significant bit is negative). Presumably the Python value is an
unsigned 32-bit type?

Use a long to avoid this (long is signed too but if you are not using the
full range of values it won't cause you a problem).

p:s
I wrote a fn to show the binary digits in the number and it gives same
output for both numbers(4278190080 and -16777216)

That's because they are the same in binary, it's just how the most
significant bit is interpretted that is different.

Dan.

 

[Ulrich Eckhardt]

i am relatively new to python..was checking out some bit shifting..
when i do
255<< 24 i get 4278190080

...which is correct, assuming a left-shift means that the value is multiplied
by 2 raised to the power of 24, although it is not common because usually
the behaviour is inherited from the CPU which uses a limited amount of
digits.

whereas in java or c it gives -16777216

...which may or may not be correct, depending on the definition. At least for
C, I believe that this causes "undefined behaviour", which is why you
should avoid using shift operations on signed types there, rather use
unsigned types. I guess that Java's VM is defined so that its shift
operations assume twos complement representations of signed integers. Can
anyone clarify that?

Further, Python as opposed to C or Java is dynamically typed. That means
that the results of

255 << 20
255 << 30

not only yield different values but also different types! This gives Python
the ability to switch to a bigger representation type where it would
overflow in C or Java. See the output of

type(255 << 20)
type(255 << 30)

for example.

I wrote a fn to show the binary digits in the number and it gives same
output for both numbers(4278190080 and -16777216)
def pBinInt(str,i):
print str,",int",i,", binary:"
print " ",
for j in range(31,-1,-1):
if(((1 << j) & i) != 0):
print 1,
else:
print 0,
print ""

#example usage pBinInt("255",255)

This is due to the fact that both are represented by the same sequence of
bits, which are only interpreted differently. Other interpretations would
be as a floating point number or a sequence of characters.


Uli

 

[devnew]

thanx for the help.. guys..
dn

 

[Patricia Shanahan]

..which is correct, assuming a left-shift means that the value is multiplied
by 2 raised to the power of 24, although it is not common because usually
the behaviour is inherited from the CPU which uses a limited amount of
digits.


..which may or may not be correct, depending on the definition. At least for
C, I believe that this causes "undefined behaviour", which is why you
should avoid using shift operations on signed types there, rather use
unsigned types. I guess that Java's VM is defined so that its shift
operations assume twos complement representations of signed integers. Can
anyone clarify that?

....

Java operator behavior is specified in the Java Language Specification,
so the same rules apply regardless of whether Java is implemented using
the JVM or not.

">>" does two's complement sign extension. See the JLS, 15.19 Shift
Operators, at
http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.19

Java does have another right shift, ">>>", that does zero fill and has
the effect of an unsigned right shift.

Patricia

 

[Daniel Pitts]

Because you are using a 32-bit int and in Java all ints are signed (the
most significant bit is negative). Presumably the Python value is an
unsigned 32-bit type?

Actually, Python values are more closely related to BigIntegers. They
grow to avoid overflow.

Use a long to avoid this (long is signed too but if you are not using
the full range of values it won't cause you a problem).


That's because they are the same in binary, it's just how the most
significant bit is interpretted that is different.

Specifically, Java interprets signed numbers as twos complement.
<http://en.wikipedia.org/wiki/Two's_complement>

Good luck,
Daniel.