[plt-dev] flvector

From: Matthew Flatt (mflatt at cs.utah.edu)
Date: Sat Dec 19 09:54:38 EST 2009

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

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

Posted on the dev mailing list.