Matthew,<br><br>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.]<br>
<br>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.<br>
<br>So, I guess the questions are:<br><br>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. <br>
<br>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.<br>
<br>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.<br>
<br>So, I think getting a really efficient implementation would require significant coordination with the PLT developers. My long-term goal (as you&#39;ve probably heard me say before) is to get a Matlab-like (or Matlab-lite) analysis capability.<br>
<br>Any thoughts?<br><br>Doug<br><br><div class="gmail_quote">On Fri, Dec 18, 2009 at 8:41 AM, Matthew Flatt <span dir="ltr">&lt;<a href="mailto:mflatt@cs.utah.edu">mflatt@cs.utah.edu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In case anyone is already using the `flvector&#39; operations, they&#39;ve<br>
moved to a new `scheme/flonum&#39; library.<br>
<br>
(I&#39;m preparing a post about `scheme/flonum&#39; for the plt-scheme list.)<br>
<br>
<br>
<br>
_________________________________________________<br>
  For list-related administrative tasks:<br>
  <a href="http://list.cs.brown.edu/mailman/listinfo/plt-dev" target="_blank">http://list.cs.brown.edu/mailman/listinfo/plt-dev</a><br>
</blockquote></div><br>