[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.


No objections.

   --Per Bothner