It's also the case that there's no language dependency on any given implementation of larger ints. We could move to a format that, though slower, would support truly arbitrary sized integers in the future, should there become a real need.
But I can assure you that such a need isn't likely. Working with very large numbers doesn't really work the same as working with small numbers. When you want to understand a number like the power-tower of 3s that is 3^3^3 high (a mammoth number, but only the first step in the 64-iteration process of producing Graham's number), representing it as a region of memory isn't really interesting. What you want to know about it are things that there are other ways to calculate, such as its modulus by certain primes, its log in various bases, etc. Aaron Sherman, M.: P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com Toolsmith, developer, gamer and life-long student. On Tue, Sep 13, 2016 at 9:12 AM, Timo Paulssen <t...@wakelift.de> wrote: > On 09/13/2016 02:26 PM, Elizabeth Mattijsen wrote: > >> On 13 Sep 2016, at 14:15, Timo Paulssen <t...@wakelift.de> wrote: > >> > >> I'll answer based on the data structures MoarVM uses internally: > >> > >> On 09/13/2016 05:13 AM, Darren Duncan wrote: > >> > >>> (Pretend the actual hardware has infinite memory so we wouldn't run > >>> out of hardware first.) > >>> > >>> 1. Maximum size of a (non-machine) integer? > >> > >> We're using libtommath, which declares the "used" and "alloc" fields of > the mp_int as "int", iow a 32bit signed (???) integer. > > eh, but Int is supposed to be a bigint, only limited by memory, no? > > > > > > Liz > > If one big integer is allowed to be 14 gigabytes big (if we use the > default of 28 bits per "mp digit"; it's also possible to use 31 or 60.), > we can still safely say "limited only by memory" for now. >
