[plt-dev] flvector

> Can you say more about what the arrays are used for?
>
> One example is raw sensor data where we are prototyping algorithms that
will be embedded in DSPs or ASICs. For example, our radar application are
processing large arrays of range-Doppler data where each entry is an
unsigned byte. Some operations (like peak detection) are more easily done in
that space.

Our image processing algorithms more efficiently look at an image as an
array of combined 8-bit red, green, blue, and alpha bytes instead of 32-bit
integer quantities. (For example, endianness isn't an issue then.) This is
where being able to stride through an array makes a lot of sense.

And, sometimes we just don't want to waste the space.


> I'd go straight for `scheme/foreign', but using `srfi/4' also seems
> fine.
>
>
I talked about this in other posts in the thread. SRFI 4 doesn't add a lot
of run-time overhead since it just re-exports the equivalent implementation
from scheme/foreign. And, I don't have to worry about the overloaded ->
operator interfering with my contracts.


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

Many languages have a separate slicing syntax that is pervasive throughout
the language. Scheme doesn't. I had though about using the 'in-range' syntax
from for, but decided it would get a bit verbose. What I have now is pretty
much the same without the 'in-range' and with wildcarding. So, (* * 2)
instead of (in-range * * 2) to mean every second index starting with 0.


>
> 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?
>
>
I think another major efficiency gain would be an efficient 'in-array'
sequence that the for operators compiled into striding through the
underlying vector.

Another thing I think would be nice, but maybe very hard, would be a
for/vector and for/array that pre-allocated the vector or array (based on
the indexing in the for). I think it would result in more readable code than
build-vector or build-array.

  (for/list ((x (in-vector v1))
             (y (in-vector v2)))
    (* x y))

would return a vector whose length is the shorter of v1 and v2.

Arrays would be similar, but would support broadcasting as in numpy to
determine the size of the resulting array. This allows (within a specific
set of rules) mixing arrays with different dimensions (including vectors and
scalars).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20091221/7de4dab0/attachment.html>