32 bit arithmetic in 2.3+

Discussion in 'Python' started by Robin Becker, Oct 23, 2003.

  1. Robin Becker

    Robin Becker Guest

    I'm sure we've had this discussion before, but I'm getting a bunch of
    problems related to various algorithms related to 32 bit arithmetic.

    The particular error/warnings I'm seeing are

    FutureWarning: hex/oct constants > sys.maxint will return positive
    values in Python 2.4 and up

    FutureWarning: x<<y losing bits or changing sign will return a long in
    Python 2.4 and up

    related to the use of 0x81020304 and << respectively.

    Can someone tell me

    1) What feature makes these warnings errors?

    2) What's the right way to do the bit shifting modulo 32 bits?
    The same kinds of problems exist in java, but we don't get the warnings
    regarding the use of 0x80000000. Do I need to replace all 0x8........
    numbers with the L version and ensure all << shifts are masked with
    0xffffffffL ? Surely there will be some compatibility issues.
    --
    Robin Becker
     
    Robin Becker, Oct 23, 2003
    #1
    1. Advertising

  2. On Thu, 23 Oct 2003 11:10:28 +0100, Robin Becker <> wrote:

    >I'm sure we've had this discussion before, but I'm getting a bunch of
    >problems related to various algorithms related to 32 bit arithmetic.
    >
    >The particular error/warnings I'm seeing are
    >
    >FutureWarning: hex/oct constants > sys.maxint will return positive
    >values in Python 2.4 and up
    >
    >FutureWarning: x<<y losing bits or changing sign will return a long in
    >Python 2.4 and up
    >
    >related to the use of 0x81020304 and << respectively.
    >
    >Can someone tell me
    >
    >1) What feature makes these warnings errors?
    >
    >2) What's the right way to do the bit shifting modulo 32 bits?
    >The same kinds of problems exist in java, but we don't get the warnings
    >regarding the use of 0x80000000. Do I need to replace all 0x8........
    >numbers with the L version and ensure all << shifts are masked with
    >0xffffffffL ? Surely there will be some compatibility issues.


    I guess the messages mean that your int objects are not the same as what int is
    to mean soon. So maybe being explicit might be the way to go? E.g.,

    class int32(int):
    # ... make it work the way you want... or make a separate int32 extension

    and use int32 instances where you have int instances now? It would also document
    your 32-bit assumptions/requirements.

    What do your 32-bit entities represent? Perhaps there is something even more
    appropriate than integers?

    If you do need good-old-32-bit-ints modeling typical 32-bit ALU behavior, and a
    lot of people need that, maybe there ought to be a built-in int32 type, or a
    parameterized fixed-width metatype, so you could say int32 = int_fixed_width(32)
    or int_sixty_four = int_fixed_width(64) etc. and tie into efficient implementation.

    Just a few rambling thoughts...

    Regards,
    Bengt Richter
     
    Bengt Richter, Oct 26, 2003
    #2
    1. Advertising

  3. Robin Becker

    Robin Becker Guest

    In article <bnfq46$8v1$0@216.39.172.122>, Bengt Richter <>
    writes
    ..
    .......
    >
    >I guess the messages mean that your int objects are not the same as what int is
    >to mean soon. So maybe being explicit might be the way to go? E.g.,
    >
    > class int32(int):
    > # ... make it work the way you want... or make a separate int32
    >extension
    >
    >and use int32 instances where you have int instances now? It would also
    >document
    >your 32-bit assumptions/requirements.
    >
    >What do your 32-bit entities represent? Perhaps there is something even more
    >appropriate than integers?


    I think you're right. These things represent the checksums done in
    typical C code where int means 32 bit unsigned. Of course the C code
    will go wrong when it moves to a 64 bit machine, but I didn't design
    true type fonts or the pdf encryption algorithms.
    >
    >If you do need good-old-32-bit-ints modeling typical 32-bit ALU behavior, and a
    >lot of people need that, maybe there ought to be a built-in int32 type, or a
    >parameterized fixed-width metatype, so you could say int32 =
    >int_fixed_width(32)
    >or int_sixty_four = int_fixed_width(64) etc. and tie into efficient
    >implementation.
    >


    This seems like an excellent idea. I suppose it could be done in Python
    first to provide a reference implementation.

    >Just a few rambling thoughts...
    >
    >Regards,
    >Bengt Richter


    It seems a bit funny to issue Future Warnings about things that I cannot
    import a __future__ feature and test any fix.
    --
    Robin Becker
     
    Robin Becker, Oct 26, 2003
    #3
  4. Robin Becker

    Miki Tebeka Guest

    Hello Robin,

    > I'm sure we've had this discussion before, but I'm getting a bunch of
    > problems related to various algorithms related to 32 bit arithmetic.
    >
    > The particular error/warnings I'm seeing are
    >
    > FutureWarning: hex/oct constants > sys.maxint will return positive
    > values in Python 2.4 and up
    >
    > FutureWarning: x<<y losing bits or changing sign will return a long in
    > Python 2.4 and up
    >
    > related to the use of 0x81020304 and << respectively.
    >
    > Can someone tell me
    >
    > 1) What feature makes these warnings errors?

    Currently bitwise operation are on the system "native" types.
    In 2.4 they will be a "logical" operation since ints and long ints
    will be unified.
    currently:
    >>> 1<<64

    __main__:1: FutureWarning: x<<y losing bits or changing sign will
    return a long in Python 2.4 and up
    0
    >>> 1L<<64

    18446744073709551616L
    >>>

    In 2.4 and up 1<<64 will give the same result as 1L<<64

    > 2) What's the right way to do the bit shifting modulo 32 bits?
    > The same kinds of problems exist in java, but we don't get the warnings
    > regarding the use of 0x80000000. Do I need to replace all 0x8........
    > numbers with the L version and ensure all << shifts are masked with
    > 0xffffffffL ? Surely there will be some compatibility issues.

    IMO this is the best way.
    def lshift32(n):
    return (n << 32) & (0xFFFFFFFF)

    HTH.
    Miki
     
    Miki Tebeka, Oct 26, 2003
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    3
    Views:
    1,764
    Timothy Bendfelt
    Jan 19, 2007
  2. joshc
    Replies:
    5
    Views:
    559
    Keith Thompson
    Mar 31, 2005
  3. Replies:
    9
    Views:
    980
    Juha Nieminen
    Aug 22, 2007
  4. Why Tea

    Arithmetic for 32-bit and 64-bit machines

    Why Tea, Jan 9, 2008, in forum: C Programming
    Replies:
    10
    Views:
    672
    cr88192
    Jan 10, 2008
  5. Jeff.M
    Replies:
    6
    Views:
    179
    Lasse Reichstein Nielsen
    May 4, 2009
Loading...

Share This Page