(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