[plt-dev] flvector

At Fri, 18 Dec 2009 10:02:23 -0700, Doug Williams wrote:
> Attached is a zip file with some homogeneous vector and array code I was
> working on in the past. The code in vtype.ss abstracts the definitions of
> the various SFRI 4 vector types (and regular Scheme vectors). The vector
> types it knows about are object (i.e., straight Scheme heterogeneous
> vectors), u(8,16,32,64), s(8,16,32,64), and f(32,64). There are also complex
> vectors of the numeric types cu(8,16,32,64), cs(8,16,32,64), and cf(32,64).
> [...]
> The intent is to provide a homogeneous array implementation similar to the
> underlying arrays in Matlab (or numpy in Python). This is what I would like
> to make more efficient and better integrated into the rest of PLT Scheme.

Can you say more about what the arrays are used for? 

I can see the use for many flavors of vectors when dealing with foreign
libraries. But is there another reason to bother with "signed 16-bit
integer" instead of just using exact integers?

> 1) Should I skip SRFI 4 altogether? The SRFI 4 implementation just exports
> things from scheme/foreign, so it would probably make sense to go straight
> to it. But, I am also using the naming convention from SRFI 4.

I'd go straight for `scheme/foreign', but using `srfi/4' also seems
fine.

> 2) How would array slicing best look syntactically? I have a simple slicing
> capability there now so you can see what it looks like. But basically, for
> any dimension, you can specify a list (start end step) and any element can
> be wildcarded using * - also, the whole dimension can be wildcarded.
> Efficient slicing (e.g., no copying required) is an important element of the
> design.

I'm not sure. I really liked using "domains" in Titanium, but I don't
have much experience with that kind of construct in other languages.

> 3) How would we best tie it to the rest og PLT Scheme? In particular, it
> would be nice to have efficient implementations of the various for routines
> that just strided through the underlying vector efficiently. But, I think
> that will require knowledge of the underlying vector type. etc and might be
> a lot of work.

For FFI purposes, I imagine adding more operations like
`{unsafe-}f64vector-ref' that to be inlined by the JIT. I'm not sure if
anything is needed for striding at the JIT level, though. Do you have
any specific operations in mind?