Matrix-type-friendly syntax and more

[kenji hara]

I got an idea for multidimentional indexing and slicing.
http://d.puremagic.com/issues/show_bug.cgi?id=6798

I think opSlice!n (n is dimension integer typed size_t) is rarely
used, therefore using that name for the enhancement is almost safe for
backward compatibility.

Kenji Hara

2011/10/10 Denis Shelomovskij <verylonglogin.reg at gmail.com>:
> 09.10.2011 21:29, bearophile пишет:
>>
>> Kenji Hara has just copied in GIT a large patch by Don:
>> https://github.com/9rnsr/dmd/branches/opDollar
>>
>> It allows user defined collections usable with this syntax:
>>
>> x[$-2, y[$-6, $-9], $-2]
>>
>> See:
>> http://d.puremagic.com/issues/show_bug.cgi?id=3474
>>
>>
>> But a syntax like this too is quite important for a user-defined matrix
>> type to be used in numerical code:
>>
>> m[i..j, k..w]
>>
>> Similar slicing and dicing of arrays is used all the time in NumPy (array
>> library for Python) code.
>>
>> This is a comment by Don about it:
>>
>>> (4) I have NOT implemented $ inside opSlice(), opSliceAssign().
>>> It could be done, but I believe those language features need work. They
>>> don't
>>> permit multi-dimensional slicing. I think they should be removed, and the
>>> functionality folded into opIndex.
>>
>> Isn't it better to improve opSlice() instead of deprecating it?
>>
>>
>> I don't remember if people appreciate the idea of a stride (like the third
>> step argument of std.range.iota), this too is used in scientific
>> array-oriented code:
>>
>> m[i..j:2, k..w:3]
>>
>> ---------------
>>
>> In Python code there is often the need for a good multi-dimensional array
>> type, even in not-scientific code.
>>
>> In the Python standard library there is a array module, but it's almost a
>> joke, it's 1D, and it's not used much:
>> http://docs.python.org/library/array.html
>>
>> Python programmers use the multi-dimensional array of NumPy, it's widely
>> used around the world, it's used by SciPy too (a scientific programming
>> library).
>>
>> The experience of Python, with its sorely felt lack of a good
>> multi-dimensional array type, the failure of its array module, and the
>> success of NumPy, the problems caused by two precedent incompatible array
>> libraries Numeric (http://people.csail.mit.edu/jrennie/python/numeric/ ) and
>> numarray
>> (http://www.stsci.edu/resources/software_hardware/numarray/numarray.html),
>> tells me that it will be good to have a bare-bones, but efficient
>> multi-dimensional array type. Plus external libraries (not present in
>> Phobos) that use those arrays to implement all the things they want.
>>
>> I think that's a good tradeoff between the opposed needs of:
>> - Keeping Phobos of reasonable size (to not increase too much the burden
>> of its management, to not slow down too much its development);
>> - Avoiding the risk of incompatible multi-dimensional array types. Most
>> code out there is able to build on a common foundation. This avoids
>> duplication (like the creation of Python numarray and Numeric), allows a
>> better focusing of efforts and speeds up the development of a language-wide
>> standard for such arrays;
>> - Offer a nD array type to the casual D programmer, even one that doesn't
>> want or can't install other libraries. Even some 30-lines long D programs
>> need multi-dimensional arrays, but they often don't need a complex
>> scientific library too (example of a problem: in the preconditions of my
>> functions that take an array of arrays I always have to test the input is
>> not jagged and it is a rectangular matrix. Such test is not necessary for a
>> multi-dimensional array that is never jagged). Putting the bare bones
>> multi-dimensional array type in Phobos allows people to use them with zero
>> other installs.
>>
>> This multi-dimensional Phobos array type doesn't even need to contain code
>> to invert a matrix or compute determinant, etc. It just needs basic
>> operations like allocation, indexing, multi-dimensional slicing, change of
>> shape, iteration... Everything else is in modules/packages external to
>> Phobos.
>>
>> I am not suggesting to put a sparse multi-dimensional array type in
>> Phobos. This need is much less common in casual short programs. This is
>> better left to external modules.
>>
>> Bye,
>> bearophile
>
> Suddenly, I had a talk with an Fortran guy at previous weekend and have
> wrote something like Fortran arrays in D last week. I had an idea of adding
> it into Phobos, but just had no time for review of my code. Draft version is
> in attachment.
>
> rarray.d - something like Fortran array
> main.d - example of using rarray module
> output.txt - main.d output
>