# 128 or 96 bit integer types?

mensanator at aol.com mensanator at aol.com
Sat Jul 28 09:19:02 CEST 2007

```On Jul 28, 12:30 am, Tim Roberts <t... at probo.com> wrote:
> "mensana... at aol.com" <mensana... at aol.com> wrote:
>
> >On Jul 27, 1:27 pm, Peter Otten <__pete... at web.de> wrote:
> >> Robert Dailey wrote:
> >> > Is there build-in or third party support for large integer types, such
> >> > as 96 or 128 bits in size? I require such large sizes for precision
> >> > issues (nanoseconds). Thanks.
> >> >>> SECOND = 10**9
> >> >>> YEAR = 365*24*60*60
> >> >>> 2**128/SECOND/YEAR
>
> >> 10790283070806014188970L
>
> >> What are you measuring? The age of the universe? In nanoseconds?
>
> >> :-)
>
> >Well, 2**96 would only be 2512308552583 years.
>
> Yes, but that's still roughly 100 times the estimated age of the universe.

Yeah, I know. I thought it was so obvious I didn't need a :-).

But _I_ won't question the need for numbers that large.
That's how I got into Python in the first place,
looking for Big Arithmetic. And I've been very happy
with it. Especially compared to the competition.
Would you believe that new F# language from Microsoft
doesn't even have an exponentiation operator? It has
a power function for floats, but not for Big Integers.
Completely worthless.

Some very simple questions can have very big answers.

For example, how many ways can you put 492 marbles into
264 ordered bins such that each bin has at least 1 marble?

66189415264331559482776409694993032407028709677550
59629130019289014193777349831417543311612293951363
4124491233746912456893016976209252459301489030

has 146 digits. And that's just the begining. The above
actually represents a polynomial with 264 terms, the
exponents of which range from 0 to 492. One of those
polynomials can have over 50000 decimal digits when
solved.

So I never let the age of the universe intimidate me.

Of course, I can't solve ALL the polynomials.
Gotta be a bit selective. :-)

```