FAQ
Hi all,

I'm having a lot of trouble with arithmetic manipulation of numbers above
0x7fffffff. Whilst an integer is represented in a 32 bit word, as you'd
expect, 0x80000000 - 0xffffffff are treated as negative numbers. However, I
want to treat a 32 bit number as an unsigned value, and be able to do i = i
+ 1 for an integer number above 0x7fffffff without getting an overflow.

I'm finding I have to use the inefficient longs for the arithmetic, and do
clumsy conversions using the struct module, e.g.

import struct

# integer to unsigned long
# in the strings, it's an upper case 'eye' and a lower case 'ell' in that
order
myUlong = struct.unpack('I', struct.pack('l',myInt))[0]

# unsigned long to integer
# in the strings, it's a lower case 'ell' and an upper case 'eye' in that
order
myInt = struct.unpack('l', struct.pack('I',myUlong))[0]

Also, I can't seem to print a long using

print '0x%08x' % myLong

if 'myLong' is greater than 0x7fffffff - I get the rather obscure 'long int
too long to convert'.

Is there a better way to do all this?

TIA

Robert Cragie

Search Discussions

  • Ray&Maria at Apr 26, 2000 at 5:55 am
    What's wrong with this:

    myInt = 0x7fffffff
    myLong = long(myInt) #coerce to long
    myInt2 = int(myLong) #coerce to int (if it fits)

    def printU32Hex(n):
    if n > 0xffffffffL:
    raise ValueError
    print "0x%01x%07x" % (int(n >> 28), int(n & 0xfffffffL))

    printU32Hex(0x7fffffffL)
    printU32Hex(0xffffffffL)
    printU32Hex(0x100000000L)

    Ray
    NOSPAMjchen at NOSPAMquark.com

    "Robert Cragie" <rcc at nospamthanks_jennic.com> wrote in message
    news:newscache$51sktf$rzc$1 at jenpc07.jennic.co.uk...
    Hi all,

    I'm having a lot of trouble with arithmetic manipulation of numbers above
    0x7fffffff. Whilst an integer is represented in a 32 bit word, as you'd
    expect, 0x80000000 - 0xffffffff are treated as negative numbers. However, I
    want to treat a 32 bit number as an unsigned value, and be able to do i = i
    + 1 for an integer number above 0x7fffffff without getting an overflow.

    I'm finding I have to use the inefficient longs for the arithmetic, and do
    clumsy conversions using the struct module, e.g.

    import struct

    # integer to unsigned long
    # in the strings, it's an upper case 'eye' and a lower case 'ell' in that
    order
    myUlong = struct.unpack('I', struct.pack('l',myInt))[0]

    # unsigned long to integer
    # in the strings, it's a lower case 'ell' and an upper case 'eye' in that
    order
    myInt = struct.unpack('l', struct.pack('I',myUlong))[0]

    Also, I can't seem to print a long using

    print '0x%08x' % myLong

    if 'myLong' is greater than 0x7fffffff - I get the rather obscure 'long int
    too long to convert'.

    Is there a better way to do all this?

    TIA

    Robert Cragie

  • Ray&Maria at Apr 26, 2000 at 6:15 am

    def printU32Hex(n):
    if n > 0xffffffffL:
    raise ValueError
    print "0x%01x%07x" % (int(n >> 28), int(n & 0xfffffffL))
    just in case someone send in int by mistake...

    def printULHex(n):
    if n > 0xffffffffL or n < 0:
    raise ValueError
    print "0x%01x%07x" % (int(n >> 28), int(n & 0xfffffffL))
  • Donn Cave at Apr 26, 2000 at 5:43 pm
    Quoth "Robert Cragie" <rcc at nospamthanks_jennic.com>:
    ...
    I guess I'm showing my C background here, but it would be nicer to have a
    notion of unsigned numbers and also to be able to print longs.

    I don't like this, as it implies that 'i' is a 32 bit signed integer, but
    you don't have any control. It blows up here because it won't extend the
    type to a long - as it's typeless, I don't see why it should be able to do
    this automatically.
    i = 0x7fffffff
    i = i + 1
    Traceback (innermost last):
    File "<pyshell#1>", line 1, in ?
    i = i + 1
    OverflowError: integer addition

    Typeless languages are all very well, but there are times when I really
    would like to say 'this is a 32 bit unsigned integer - treat it as such'
    instead of implied typing. The warning bells sounded a bit on p33 of
    'Learning Python' when it suggested that "as a rule of thumb, if you find
    yourself wanting to flip bits in Python, you should think long and hard
    about which language you're really using". But there are more compelling
    reasons why I am using Python than C for my particular application. I don't
    particularly want to have to start writing C companion libraries if I can
    avoid it.
    I guess there's a tension here between these somewhat exotic
    applications and more general aspirations for Python, where
    even the present reliance on machine numerical types is arguably
    inappropriate. I personally feel that Python's position on the
    Very High Level scale here is just typical of its practicality,
    but with the unsigned integer, in C we have an example to be
    avoided. I mean, its rules for operations on unsigned integers
    make some sense insofar as I can see, but the ANSI library
    standards are clearly on a different page about it with things
    like strlen() returning unsigned integers. If the arbiters of
    ANSI C can't even keep it straight, how can Python users be
    expected to sort these things out?

    Anyway, rant over, it's not entirely clear which way you want to
    go, but I think you want 0x7fffffff to roll over to 0x80000000
    regardless of hardware integer size, without the overflow exception.
    Would it be reasonable, considering that this is an exotic and
    not generally useful behavior, to do that kind of arithmetic with
    a functional notation like c = uadd(a, b, 32), c = umul(a, b, 32)?

    Ironically our high level language looks a little like assembly
    language here, but then neither one has any notion of type declaration
    so perhaps it's inevitable.

    Donn Cave, University Computing Services, University of Washington
    donn at u.washington.edu
  • Robert Cragie at Apr 26, 2000 at 8:31 am
    Ray&Maria <nospam at nowhere.net> wrote in message
    news:PxvN4.1335$sf5.16905 at news.corecomm.net...
    What's wrong with this:

    myInt = 0x7fffffff
    myLong = long(myInt) #coerce to long
    myInt2 = int(myLong) #coerce to int (if it fits)

    def printU32Hex(n):
    if n > 0xffffffffL:
    raise ValueError
    print "0x%01x%07x" % (int(n >> 28), int(n & 0xfffffffL))

    printU32Hex(0x7fffffffL)
    printU32Hex(0xffffffffL)
    printU32Hex(0x100000000L)
    Nothing at all in principle, but it would be nice to have a neater solution.
    I guess I'm showing my C background here, but it would be nicer to have a
    notion of unsigned numbers and also to be able to print longs.

    I don't like this, as it implies that 'i' is a 32 bit signed integer, but
    you don't have any control. It blows up here because it won't extend the
    type to a long - as it's typeless, I don't see why it should be able to do
    this automatically.
    i = 0x7fffffff
    i = i + 1
    Traceback (innermost last):
    File "<pyshell#1>", line 1, in ?
    i = i + 1
    OverflowError: integer addition

    Typeless languages are all very well, but there are times when I really
    would like to say 'this is a 32 bit unsigned integer - treat it as such'
    instead of implied typing. The warning bells sounded a bit on p33 of
    'Learning Python' when it suggested that "as a rule of thumb, if you find
    yourself wanting to flip bits in Python, you should think long and hard
    about which language you're really using". But there are more compelling
    reasons why I am using Python than C for my particular application. I don't
    particularly want to have to start writing C companion libraries if I can
    avoid it.

    Robert
  • Thomas Heller at Apr 26, 2000 at 9:44 am

    Hi all,

    I'm having a lot of trouble with arithmetic manipulation of numbers above
    0x7fffffff. Whilst an integer is represented in a 32 bit word, as you'd
    expect, 0x80000000 - 0xffffffff are treated as negative numbers. However, I
    want to treat a 32 bit number as an unsigned value, and be able to do i = i
    + 1 for an integer number above 0x7fffffff without getting an overflow.
    What about writing an Uint32 class? You could implement __add__, __hex__,
    and so on...

    Thomas

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedApr 25, '00 at 1:53p
activeApr 26, '00 at 5:43p
posts6
users4
websitepython.org

People

Translate

site design / logo © 2022 Grokbase