32 bit arithmetic in 2.3+

[Robin Becker]

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.

 

[Bengt Richter]

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

 

[Robin Becker]

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.

 

[Miki Tebeka]

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:__main__:1: FutureWarning: x<<y losing bits or changing sign will
return a long in Python 2.4 and up
0In 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