<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Can you say more about what the arrays are used for?<br>
<br></blockquote><div>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.<br>
<br>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.<br>
<br>And, sometimes we just don't want to waste the space.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>I'd go straight for `scheme/foreign', but using `srfi/4' also seems<br>
fine.<br>
<div class="im"><br></div></blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
<br>
</div>I'm not sure. I really liked using "domains" in Titanium, but I don't<br>
have much experience with that kind of construct in other languages.<br></blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
<br>
</div>For FFI purposes, I imagine adding more operations like<br>
`{unsafe-}f64vector-ref' that to be inlined by the JIT. I'm not sure if<br>
anything is needed for striding at the JIT level, though. Do you have<br>
any specific operations in mind?<br>
<br>
</blockquote></div><br>I think another major efficiency gain would be an efficient 'in-array' sequence that the for operators compiled into striding through the underlying vector.<br><br>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.<br>
<br> (for/list ((x (in-vector v1))<br> (y (in-vector v2)))<br> (* x y))<br><br>would return a vector whose length is the shorter of v1 and v2.<br><br>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).<br>
<br><br>