Unsigned integer arithmetic

[Donn Cave]

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