belated feedback Alex Shinn (16 Apr 2021 15:00 UTC) Re: belated feedback Bradley Lucier (16 Apr 2021 17:08 UTC) Re: belated feedback John Cowan (16 Apr 2021 18:25 UTC) Re: belated feedback Bradley Lucier (17 Apr 2021 21:48 UTC) Re: belated feedback Alex Shinn (18 Apr 2021 23:45 UTC) Re: belated feedback Bradley Lucier (16 Apr 2021 23:46 UTC) Re: belated feedback Alex Shinn (17 Apr 2021 00:03 UTC) Re: belated feedback Bradley Lucier (17 Apr 2021 01:10 UTC) Re: belated feedback Alex Shinn (17 Apr 2021 01:22 UTC) Re: belated feedback Alex Shinn (30 Apr 2021 05:41 UTC) Re: belated feedback Bradley Lucier (30 Apr 2021 14:17 UTC) Re: belated feedback John Cowan (30 Apr 2021 15:04 UTC) Re: belated feedback Bradley Lucier (30 Apr 2021 16:42 UTC) Re: belated feedback Alex Shinn (01 May 2021 09:27 UTC) array-elements-in-order? (Was: belated feedback) Bradley Lucier (16 Jan 2022 19:08 UTC)

Re: belated feedback Alex Shinn 01 May 2021 09:27 UTC

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