This page is part of the web mail archives of SRFI 25 from before July 7th, 2015. The new archives for SRFI 25 contain all messages, not just those from before July 7th, 2015.
S.H.M.J. Houben wrote on Mon, 2001 Nov 12:
> Interesting proposal.
>
> But of course lots of remarks:
Thanks. Sorry for the delay - you were so fast I was not on the list
myself yet, so I did not have your message at hand to follow up to.
(I did a lynx -dump to a *mail* buffer now.)
> 1. The functionality of multi-dimensional arrays can also be
> provided by nested 1-dimensional arrays. It is unclear to me why
> multi-dimensional arrays are needed at all.
I'm afraid ultimately they are not needed, but then one-dimensional
arrays are not ultimately needed either.
> What is the motivation: efficiency (and if so, explain how the
> proposal is more efficient)
The share-array magic provides a lot. A simple example: define a dot
product for one-dimensional arrays, and then apply it to rows and
columns of matrices. With vector-of-vectors, you have to copy each
column, if not each row. With truly shared arrays, you need not.
I have not timed anything, though.
> or added functionality (and if so,
> give an example of things we can do with SRFI-25 not easily done
> with R5RS vectors).
Look at the transpose in the "tools file" linked from the Examples
section. (Weird - netscape thinks it is "untyped binary data". All the
files are source code and contain only ASCII bytes.) It just permutes
the index list and accesses the original array.
> 2. I don't think array-dimensions is a good name. I would [...]
> what about calling it array-number-of-dimensions ?
Too unwieldy. I'd rather call it haulong. What about array-dim? Or
array-rank again, though somebody used to oppose that (because matrix
rank is something else altogether).
> 3. I don't like the shape format. It is logically a list of pairs:
> why not write it as one: e.g. ((0 4) (0 4)) looks better to me
> than (0 4 0 4). For 0-based arrays the shorthand (4 4)
> could then be used.
A list of pairs would be ((0 . 4) (0 . 4)), so there is already an
arbitrariness there. Yes, the bounds come logically in pairs, but I do
not agree about any particular data structure being logical. To really
write what the shape is I would write
(cartesian-product
(integers-between b0 e0)
(integers-between b1 e1)
...).
Also, (shape 0 4 0 4) does not get more complicated when an individual
index expression gets more complicated. List structure would really
favour constant bounds. Compare
(shape b (* 2 e) b (+ e 1))
(list (list b (* 2 e)) (list b (+ e 1)))
and also notice that the very word "shape" there communicates intent
to the reader, while "list" does not.
> 4. Apparently arrays are supposed to be disjoint from vectors.
> This could be made more explicit. Also, this means that even
> 1-dimensional 0-based arrays are disjoint from vectors?
Hm. Maybe that should be more explicit. Yes, I think they are best
disjoint. Array-ref and friends might be able to access vectors
transparently, with runtime cost, but I would not want to ask
implementors to make vector-ref and friends able to access certain
kinds of multidimensional arrays. They might just refuse.
> 5. From reading the proposal I understand that () is a valid shape,
> but perhaps this point could be clarified separately.
No, a zero-times-two array is a valid shape, returned by (shape). It
is a natural limiting case, the shape of zero-dimensional arrays. I
have some text about that somewhere, but I do not think I want to
expand on it in the specification.
> 6. share-array says that a linear procedure must be given, and
> that "a constant term is just a special case". Could it be that
> "affine" is meant instead of "linear"?
You appear to be right. I will change that. My ignorance.
> 7. I would rename build-array to tabulate-array . There is little
> difference, in my mind, between making and building an array.
I agree. Good names do not come for free. Thanks.
I will not bother the editors with that, though, as build-array is not
in the specification. It is currently an illustration only: the Issues
section is just for the discussion.
(Sigh. I exaggerated the number of times Brian Denney sent his mail
bomb. Sorry for that.)
--
Jussi