[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: various comments
Jussi Piitulainen wrote:
Just like srfi-25. If I understand correctly, CL transformation maps
are much more restricted.
Yes, they only support a simple displacement, enough to implement
sub-sequences (a la shared substring).
[Adjusting an array] If the existing data array is large enough for
the new size, we should allow an implementation to re-use the
existing data array, for efficiency;
That might not be easy. The data under srfi-25 may be in quite
different order in the array and in its backing vector.
Yes. It mainly is useful when adjusting (increasing or reducing)
the "major" dimension - and msotly only for one-dimensions arrays.
Note an implication of this representation is that you don't want to
use a general array for a shape. Instead' you'd want a shape to be a
simple (but read-only) vector. So I strongly suggest that the
specification be changed to make shape be a *one*-dimensional array
- or better yet make it an unspecified opaque type. (In that case
for Kawa I would use a simple Java primitive int array.)
We could easily make shapes their own type, with accessors
(shape-begin shp k)
(shape-end shp k) for 0 <= k < (shape-length shp),
say, or replace (array-shape arr) with
(array-begin arr k)
(array-end arr k) for 0 <= k < (array-rank arr),
so shapes could still be arrays but a shape of an array would not be
accessible, if that would really be useful in practice.
It might be useful to have both, where array-begin is a convenience function
(and possible optimization) of shape+shape-begin.
But I'd like
to keep arbitrary lower bounds, even if they most often are zeroes.