32 bit arithmetic in 2.3+

[Bengt Richter]

On Thu, 23 Oct 2003 11:10:28 +0100, Robin Becker <robin at jessikat.fsnet.co.uk> 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