Matrix-type-friendly syntax and more

[kennytm]

"Robert Jacques" <sandford at jhu.edu> wrote:
> On Mon, 10 Oct 2011 08:46:05 -0400, kennytm <kennytm at gmail.com> wrote:
>> Don <nospam at nospam.com> wrote:
>>> On 10.10.2011 04:41, kenji hara wrote:
>>>> 2011/10/10 bearophile<bearophileHUGS at lycos.com>:
>>>>> 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?