Posted pull request. https://github.com/D-Programming-Language/dmd/pull/443
This patch does not break existing codes (at least dmd test suite and phobos building). I have not added stride syntax (e.g. a[0..$:2]), but I think that adding it is not so difficult. Kenji Hara 2011/10/10 kenji hara <[email protected]>: > 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 <[email protected]>: >> 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 >> >
