On Sat, May 1, 2021 at 1:42 AM Bradley Lucier <xxxxxx@math.purdue.edu> wrote:
>
> On 4/30/21 11:04 AM, John Cowan wrote:
> > I don't understand your reasoning here.
>
> Well, in three dimensions the general case is
>
>                (lambda (i j k)
>                  (+ base
>                     (* increment-0 (- i low-0))
>                     (* increment-1 (- j low-1))
>                     (* increment-2 (- k low-2))))
>
> I guess what I call increments other people might call strides.
>
> It could happen that an index and the associated increment and lower
> bound are all fixnums, but the product of the increment and the lower
> bound is a bignum.  (It's not that hard on a 32-bit machine.)

I think that John's point was that the results of the indexers are
bounded by virtual memory space, which will tend to fit in a fixnum.
If you assume zeros for the lower bounds, then with the default
indexer all intermediate computations also fit in fixnums, and
likely so even after any of the SRFI 179 provided transformations.

The assumption doesn't hold at all on 32-bit machines, and even on
64-bit you can get close to bignums - you can currently access 2^52
indexes of a u1vector on Solaris, and MIT Scheme fixnums only
go up to 2^57.  On SPARC 2015 with 64-bit virtual and 56-bit physical
memory you can already exceed this.

One can also imagine a storage class backed by networked or
filesystem memory which could easily exceed these limits.

With non-zero lower bounds it's easy to push these computations
into bignum space, but you can also make the lower bounds
themselves bignums to begin with.

The common case is optimized either way.  With Brad's approach
the transformed cases are pessimized slightly in exchange for a bigger
optimization in some rarer cases.  There are slow pathological cases
regardless.

--
Alex