Home Original page

Integer arithmetic

Alex Martelli aleax at aleax.it
Wed Mar 26 05:55:41 EST 2003 
Daniel Timothy Bentley wrote:

> Am I so far off in thinking maybe this should be provided by the language?

IMHO, you are.  "integral types with N bits ignoring overflows" is
a very marginal "niche" requirement; the language would grow far too
big if it was to provide all such marginalia!  It's easy, when one is
developing in a focused way in a specific application area, to start
wishing for one's language to provide just the primitives that would
be most convenient for that specific need.  But unless a primitive
has WIDE use over a large variety of application areas, the language
IS better off without it -- that's what LIBRARIES are for!


> Some way to create an int, using some (perhaps implementation-defined)
> method of changing a long to an int?

Why?  What's wrong with int(thelong & amask)?

> Some way to ensure that I don't
> misguess on what themask is?  What if I'm programming on a machine with 36
> bit longs?  Or where 64 bits is the atomic datatype?

I see you've already been advised to use sys.maxint, which is fine if
what you want is to use "integers of the exact number of bits which
happen to be provided by this specific piece of hardware".  I did not
think you wanted that variability in your "C interpreter", so I chose
to provide, instead, "32-bit integers" anyway, ignoring the underlying
platform.

Isn't it WONDERFUL that the language does NOT provide a hard-coded
"way to create an int from a long", so you can easily CHOOSE depending
on your application's need how and whether to truncate longs that
are too large?

For example, if you're interested in simulating a decimal machine,
where integers have N digits rather than N bits, then instead of
bitmasking you just use int(thelong % biggie) where biggie=1000000
or whatever.  Isn't that the cat's pajamas?


Alex
More information about the Python-list mailing list