Matrix-type-friendly syntax and more

[Robert Jacques]

On Tue, 11 Oct 2011 01:57:06 -0400, kennytm <kennytm at gmail.com> wrote:
> "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?
>

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]