[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: various comments

This page is part of the web mail archives of SRFI 25 from before July 7th, 2015. The new archives for SRFI 25 are here. Eventually, the entire history will be moved there, including any new messages.

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