SRFI 231: Importing existing data Jens Axel Søgaard (12 Jan 2022 18:53 UTC)
Re: SRFI 231: Importing existing data Bradley Lucier (12 Jan 2022 20:59 UTC)
Re: SRFI 231: Importing existing data Jens Axel Søgaard (13 Jan 2022 15:42 UTC)
Re: SRFI 231: Importing existing data Bradley Lucier (16 Jan 2022 01:55 UTC)
Re: SRFI 231: Importing existing data Jens Axel Søgaard (18 Jan 2022 12:19 UTC)
Re: SRFI 231: Importing existing data Bradley Lucier (24 Apr 2022 16:55 UTC)
Re: SRFI 231: Importing existing data Jens Axel Søgaard (24 Apr 2022 17:00 UTC)

Re: SRFI 231: Importing existing data Bradley Lucier 12 Jan 2022 20:59 UTC

On 1/12/22 1:52 PM, Jens Axel Søgaard wrote:
> Suppose a user has data he wants to use a body of a specialized array.
> Is there a way to construct a specialized array reusing the existing
> value (i.e. no copying)?
>
> If not I suggest adding a `make-specialized-array-from-body` operation.

I'll think about how to do this.  Some initial thoughts are as follows:

1. A "body" in the sense of a storage-class or an array is not always
simply a vector-like object, it can be a compound object like in
u1-storage-class, for which a body is a two-element vector with the
number of 1-bit elements as the first component and a u16vector as the
second.

2. I think the calling sequence should be something like

(make-specialized-array-from-data storage-class data)

which will make a one-dimensional array from the data.  With
array-extract, specialized-array-reshape, and specialized-array-share
one can reshape the initial array to whatever one might like.

3.  So it would seem that a storage class will need a routine that
checks that vector-like data is compatible with the storage class, and a
routine that constructs an initial "body" from the "data".

4.  The "data" that one passes to this routine may be implementation
dependent.  For example, if an underlying implementation has bitvectors
(as it seems you're using for the Racket implementation) that that is
what should be passed as data, instead of the u16vectors in the
reference implementation.  Similarly, Gambit uses a struct of two 32-bit
unsigned ints to implement unsigned 64bit ints on architectures for
which 64-bit unsigned ints aren't available.  Perhaps each
implementation should state which type of data goes with each storage class.

Brad