Matrix-type-friendly syntax and more

[Robert Jacques]

On Tue, 11 Oct 2011 11:48:54 -0400, Gor Gyolchanyan <gor.f.gyolchanyan at gmail.com> wrote:
> 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.

First, slicing / striding doesn't imply copying.

Second, striding allows you to mutate the original data, which many lazy ranges do not.

Third, there is a heavy amount of over-head to opApply, as its delegate based.

Forth, declaring a custom type is way too much programmer boilerplate, even using something like Tuple!(ubyte,ubyte,ubyte,ubyte) is overly verbose.

Fifth, my example was about dynamically supporting multiple data formats using the same code, something not possible with a custom struct.

Sixth, we are talking about multi-dimensional arrays, not D's built-in arrays; lazy ranges don't exactly apply. Although, on the subject of Multi-dimensional ranges/iteration, has anyone else taken a look at the FLAME project? (http://z.cs.utexas.edu/wiki/flame.wiki)

Seventh, Matlab, NumPy, Octave, BLAS, etc. all support striding.