On Tue, 11 Oct 2011 01:57:06 -0400, kennytm <[email protected]> wrote:
"Robert Jacques" <[email protected]> wrote:
On Mon, 10 Oct 2011 08:46:05 -0400, kennytm <[email protected]> wrote:
Don <[email protected]> wrote:
On 10.10.2011 04:41, kenji hara wrote:
2011/10/10 bearophile<[email protected]>:
So is this:
y[$-6, 0..$:2]
Translated like this?
y.opIndex(y.opDollar!0 - 6, y.opSlice!1(0, y.opDollar!1, 2))
I have no thought about it.
I'm not sure that the additional stepping is really useful, but I
think adding it into syntax is not impossible -- it might not conflict
with associative array literal.
Kenji Hara
Personally, I think that since strided operations are so inefficient,
they should remain ugly.
Slicing an nD static array is just as in/efficient as strides. That said,
I'm still -1 on having a..b:c since (1) I see no practical need for strides
and (2) even if we striding it doesn't need to be in the form a..b:c, e.g.
arr[stride(0..$, 2)].
Regarding (1), from a computer vision/graphics perspective, being able to
only operate on the red channel, for example, is very nice. And I use
striding all the time in my CUDA code, but that's not as applicable in D,
yet. Striding tends to be most useful for working with packed data of some kind.
Why not use a 'Color' struct?
Not all images have the same layout, so having a single Color struct doesn't
cut it. (RGB, RGBA, BGR, BGRA, ARGB, ABGR) Although, being able to say:
structArr[0..$].red; would be very handy indeed. But all that is / should be is
a opDispatch wrapper around a strided operation: byteArr[2..$:3]
