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)
|
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