f



left shift

hii am relatively new to python..was checking out some bit shifting..when i do255<< 24  i get  4278190080whereas in java or c it gives  -16777216can someone tell me why this is ?,what should i do if i want theoutput as -16777216 ?dnp:sI wrote a fn to show the binary digits in the number and it gives sameoutput 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)
0
devnew (32)
10/22/2007 9:37:10 AM
comp.lang.java.programmer 52711 articles. 1 followers. Post Follow

5 Replies
543 Views

Similar Articles

[PageSpeed] 23

On Mon, 22 Oct 2007 10:37:10 +0100, devnew@gmail.com <devnew@gmail.com>  wrote:> 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.-- Daniel Dyerhttp://www.uncommons.org
0
Daniel
10/22/2007 9:51:29 AM
devnew@gmail.com wrote:> 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 multipliedby 2 raised to the power of 24, although it is not common because usuallythe behaviour is inherited from the CPU which uses a limited amount ofdigits.> whereas in java or c it gives  -16777216...which may or may not be correct, depending on the definition. At least forC, I believe that this causes "undefined behaviour", which is why youshould avoid using shift operations on signed types there, rather useunsigned types. I guess that Java's VM is defined so that its shiftoperations assume twos complement representations of signed integers. Cananyone clarify that?Further, Python as opposed to C or Java is dynamically typed. That meansthat the results of   255 << 20  255 << 30not only yield different values but also different types! This gives Pythonthe ability to switch to a bigger representation type where it wouldoverflow 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 ofbits, which are only interpreted differently. Other interpretations wouldbe as a floating point number or a sequence of characters.Uli-- Sator Laser GmbHGeschäftsführer: Ronald Boers, Amtsgericht Hamburg HR B62 932
0
Ulrich
10/22/2007 10:20:38 AM
thanx for the help.. guys..dn
0
devnew
10/22/2007 1:41:10 PM
Ulrich Eckhardt wrote:> devnew@gmail.com wrote:>> 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?....Java operator behavior is specified in the Java Language Specification,so the same rules apply regardless of whether Java is implemented usingthe JVM or not.">>" does two's complement sign extension. See the JLS, 15.19 ShiftOperators, athttp://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.19Java does have another right shift, ">>>", that does zero fill and hasthe effect of an unsigned right shift.Patricia
0
Patricia
10/22/2007 1:45:35 PM
Daniel Dyer wrote:> On Mon, 22 Oct 2007 10:37:10 +0100, devnew@gmail.com <devnew@gmail.com> > wrote:> >> 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?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).> >> 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.Specifically, Java interprets signed numbers as twos complement.<http://en.wikipedia.org/wiki/Two's_complement>Good luck,Daniel.-- Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
0
Daniel
10/22/2007 2:53:47 PM
Reply: