Integer arithmetic

[Daniel Timothy Bentley]

It seems like so long as there's a distinction in the language between
ints and longs, there should be a way to create ints reliably.

If

int(foo % sys.maxint)

is such a call, great.  Is this guaranteed to work?  I don't know.

Basically, if you're going to say ints and longs are separate types, I
think there should be a way to makes ints from longs fairly reliably.  I
don't think that's a niche, I think it's something a consistent language
should provice.

Maybe python is moving towards a day where ints and longs are completely
indistinguishable.  This probably wouldn't be a bad thing, from many
standpoints.  But until that day comes, I think that there should be a way
to construct an object without getting an exception.  I guess it's more a
matter of taste whether the implentation or the interface-user should do
it, but since one still allows the other, I'd say the implementation
probably should.

I like the flexibility python provides, but it seems that there might be
cracks where orthogonality or consistency of interface have cracks; which
makes sense in an evovling language.  If I managed to arrive at python at
a point where this "problem" was just begotten and there's a good chance
it will go away soon, perfect.  But I stil think there's an elegant
solution to be had, that works across implementations.  Is it sys.maxint?
Maybe.  Silent exceptions, like Java will do for math stuff?  Maybe.  I'm
getting the impression the solution is maxint, so great.  Thanks.

-Dan

On Wed, 26 Mar 2003, Alex Martelli wrote:

> 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
>
>