Matrix-type-friendly syntax and more

Gor Gyolchanyan gor.f.gyolchanyan at gmail.com
Tue Oct 11 08:48:54 PDT 2011


I don't think strides are necessary. You can always opApply your image
in a certain way. Define a private struct, which has an opApply, which
iterates over every third channel of each pixel.
lazy ranges are generally better, then arrays, because with them, you
can avoid copying anything altogether.

On Tue, Oct 11, 2011 at 6:36 PM, Robert Jacques <sandford at jhu.edu> wrote:
> 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]
>


More information about the Digitalmars-d mailing list