(Previous discussion continued)
Re: Terminology: fixed-array => eager-array? Jamison Hope 05 Aug 2015 15:20 UTC

Re: Terminology: fixed-array => eager-array? Jamison Hope 05 Aug 2015 15:20 UTC

On Aug 5, 2015, at 10:53 AM, Bradley Lucier <xxxxxx@purdue.edu> wrote:

>> On Aug 5, 2015, at 10:33 AM, Jamison Hope <xxxxxx@alum.mit.edu> wrote:
>>
>> I don't think "eager" is the right word, either.  Retrieving a value via
>> pointer arithmetic is certainly simple, but it is no more eager than
>> retrieving a value via a hash table lookup or getting a value out of a
>> sparse array stored as a linked list (put another way, hash tables and
>> sparse arrays are not necessarily lazy).
>
> Let’s leave sparse arrays and hash tables out of it for now.
>
> What I mean by “eager” is that whatever computations are needed to compute (getter i j) for all (i j) are done “ahead of time” and the values are sitting there ready to retrieve.
>
> I’m not saying that “eager” is better than “simple”, it just seems I didn’t explain myself clearly enough.

No, I understood you correctly.  My point is that "eagerness" is not the
characteristic that distinguishes arrays-laid-out-sequentially-in-memory
from other types of array-like (numerically indexable) things.  The values
of all array elements, i.e. the value of (getter i j) for all (i j), can
be resident in memory (already computed) without being laid out
sequentially in a vector.  Any number of data structures could be used as
the backing store.

So, which characteristic are you intending for all fixed-array instances
to share?  The talk about affine transformations and backing vectors makes
it sound like it's the stored-at-sequential-memory-addresses part.  It is
a logical consequence that they will also be eager, yes, but the converse
doesn't hold.  "eager-array" is too broad.

Unless it truly is the eagerness that is the intended defining
characteristic, in which case all the talk about backing vectors and affine
transformations should go away (or be moved), to allow for other data
structures behind the scenes.

--
Jamison Hope
xxxxxx@alum.mit.edu