[plt-dev] flvector

Matthew,

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 code in type-vector.ss abstracts the vector types describes in vtype.ss
into a single typed-vector type. The code in array.ss provides the array
abstraction with the underlying data stored as a typed-vector. Finally, the
array-test.ss test the array abstraction. [Just running array-test.ss will
give you a pretty good idea about the array abstraction.]

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.

So, I guess the questions are:

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.

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.

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.

So, I think getting a really efficient implementation would require
significant coordination with the PLT developers. My long-term goal (as
you've probably heard me say before) is to get a Matlab-like (or
Matlab-lite) analysis capability.

Any thoughts?

Doug

On Fri, Dec 18, 2009 at 8:41 AM, Matthew Flatt <mflatt at cs.utah.edu> wrote:

> In case anyone is already using the `flvector' operations, they've
> moved to a new `scheme/flonum' library.
>
> (I'm preparing a post about `scheme/flonum' for the plt-scheme list.)
>
>
>
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20091218/e387856d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: array.zip
Type: application/zip
Size: 8833 bytes
Desc: not available
URL: <http://lists.racket-lang.org/dev/archive/attachments/20091218/e387856d/attachment.zip>