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 16 Jan 2022 01:55 UTC

On 1/13/22 10:42 AM, Jens Axel Søgaard wrote:
> Den ons. 12. jan. 2022 kl. 21.59 skrev Bradley Lucier
> <xxxxxx@math.purdue.edu <mailto:xxxxxx@math.purdue.edu>>:
>
>     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
>
>
> I began writing an implementation from scratch. Got a deja-vu and
> remembered I actually implemented a data/bitvector years ago.
>
>     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.
>
>
> This sounds like a fine design. Separating data from body is a good idea.
>
> /Jens Axel

This branch:

https://github.com/gambiteer/srfi-231/tree/specialized-from-data

now has a preliminary implementation of make-specialized-array-from-data
that needs more tests in test-arrays.scm.  The commit is

https://github.com/gambiteer/srfi-231/commit/c79037cf4cea7cfb73cec71c3c3d5b492394cd56

I welcome comments about implementation, documentation, testing, etc.

I particularly welcome ideas for randomized testing in the style of the
rest of test-arrays.scm.  I'll continue to think of my own tests.

Brad