This is the start of the two week formal review for the proposed std.range.ndslice. This new addition to the standard library would add the ability to create and manipulate multi-dimensional random access ranges in a way that will be very familiar to those of you who use numpy. This has the potential to give D a huge boost in popularity in numerical and scientific applications.

A quick run down for those that are not familiar with the process. After two weeks, the PR author (Ilya Yaroshenko) will have time to make proposed changes. Then, when the author feels it's ready, the PR will go to a vote. In the vote, everyone in the community has a say, but if one of the main contributors or maintainers has a very negative opinion (for example) that will carry more weight.

Github: https://github.com/D-Programming-Language/phobos/pull/3397
dub: http://code.dlang.org/packages/dip80-ndslice
docs: http://dtest.thecybershadow.net/results/bac6211c1d73b2cf62bc18c9844c8c82c92c21e1/5c6071ca953cf113febd8786b4b68916cbb2cdaf/

previous discussion: http://forum.dlang.org/thread/rilfmeaqkailgpxoziuo@forum.dlang.org

On Monday, 16 November 2015 at 22:45:35 UTC, Jack Stouffer wrote:
> This is the start of the two week formal review for the proposed std.range.ndslice. This new addition to the standard library would add the ability to create and manipulate multi-dimensional random access ranges in a way that will be very familiar to those of you who use numpy. This has the potential to give D a huge boost in popularity in numerical and scientific applications.

One thing that stands out is the number of symbols in the Slice struct that have simple "///" doc comments. That is, they show up in the generated documentation without any explanation.

On Tuesday, 17 November 2015 at 00:10:42 UTC, Brian Schott wrote:
> On Monday, 16 November 2015 at 22:45:35 UTC, Jack Stouffer wrote:
>> This is the start of the two week formal review for the proposed std.range.ndslice. This new addition to the standard library would add the ability to create and manipulate multi-dimensional random access ranges in a way that will be very familiar to those of you who use numpy. This has the potential to give D a huge boost in popularity in numerical and scientific applications.
>
> One thing that stands out is the number of symbols in the Slice struct that have simple "///" doc comments. That is, they show up in the generated documentation without any explanation.

Thanks! Fixed
http://dtest.thecybershadow.net/artifact/website-7a646fdea76569e009844cdee5c93edab10980ca-2b25fcf8789289fb52e50e2e71914d1a/web/phobos-prerelease/std_experimental_range_ndslice.html

--Ilya

On Monday, 16 November 2015 at 22:45:35 UTC, Jack Stouffer wrote:
> This is the start of the two week formal review for the proposed std.range.ndslice. This new addition to the standard

Why can't byElement

http://dtest.thecybershadow.net/artifact/website-7a646fdea76569e009844cdee5c93edab10980ca-2b25fcf8789289fb52e50e2e71914d1a/web/phobos-prerelease/std_experimental_range_ndslice.html#.byElement

provide RandomAccess? It's documented to return an InputRange.

On Tuesday, 17 November 2015 at 10:13:57 UTC, Nordlöw wrote:
> Why can't byElement
>
> http://dtest.thecybershadow.net/artifact/website-7a646fdea76569e009844cdee5c93edab10980ca-2b25fcf8789289fb52e50e2e71914d1a/web/phobos-prerelease/std_experimental_range_ndslice.html#.byElement
>
> provide RandomAccess? It's documented to return an InputRange.

AFAIK, if all the slice dimensions are know at compile-time it should. This is kind of similar to how std.range.chain() works.

On Monday, 16 November 2015 at 22:45:35 UTC, Jack Stouffer wrote:
> docs: http://dtest.thecybershadow.net/results/bac6211c1d73b2cf62bc18c9844c8c82c92c21e1/5c6071ca953cf113febd8786b4b68916cbb2cdaf/

There seems to be a mis-spelling of experimental as experemental:

Search for: std/experemental/range/ndslice.d

On Tuesday, 17 November 2015 at 10:19:26 UTC, Nordlöw wrote:
> There seems to be a mis-spelling of experimental as experemental:

Here: http://dtest.thecybershadow.net/artifact/website-7a646fdea76569e009844cdee5c93edab10980ca-2b25fcf8789289fb52e50e2e71914d1a/web/phobos-prerelease/std_experimental_range_ndslice.html

On Tuesday, 17 November 2015 at 10:16:56 UTC, Nordlöw wrote:
> On Tuesday, 17 November 2015 at 10:13:57 UTC, Nordlöw wrote:
>> Why can't byElement
>>
>> http://dtest.thecybershadow.net/artifact/website-7a646fdea76569e009844cdee5c93edab10980ca-2b25fcf8789289fb52e50e2e71914d1a/web/phobos-prerelease/std_experimental_range_ndslice.html#.byElement
>>
>> provide RandomAccess? It's documented to return an InputRange.
>
> AFAIK, if all the slice dimensions are know at compile-time it should. This is kind of similar to how std.range.chain() works.

Thanks! Implemented: http://dtest.thecybershadow.net/artifact/website-7a646fdea76569e009844cdee5c93edab10980ca-4f243752aee5ecc098ce1c36eedd86a2/web/phobos-prerelease/std_experimental_range_ndslice.html#byElement

--Ilya

On Monday, 16 November 2015 at 22:45:35 UTC, Jack Stouffer wrote:
> docs: http://dtest.thecybershadow.net/results/bac6211c1d73b2cf62bc18c9844c8c82c92c21e1/5c6071ca953cf113febd8786b4b68916cbb2cdaf/

I have already posted some things on Github, so If you will indulge me signing the praises of this addition for a moment:

Something dawned on me when I was scanning the numpy documentation, looking for anything obvious that was missed by this PR. What I noticed is that D really made the right bet when it came to putting a lot of range code in the standard library, because in order to make numpy useful at all, the authors had to recreate parts of the Python standard library in their C code so that it takes advantage of the type information that numpy arrays provide, where as all of std.algorithm and std.range can be used with this no problem. For example to create a zero initialized n-d array in numpy, you would have to use the numpy function np.zeros((10, 5)), but with this you can repeat(0, 50).sliced(10, 5) with no performance penalty. In numpy to take the sum of a certain axis, you can use Python's len or sum like sum(array[:, 0]) but it's slow so you have to remember the special case that you need to use array[:, 0].sum() instead to take advantage of numpy's types. With this it's just array[0..$, 0].sum with the same function you always use in the way you always use it. There are a ton of these special cases, and the consequence is it makes it very hard for non numpy code and numpy code to mix in a way that doesn't incur penalties or is a huge pain.

Also, this is a great showcase for how powerful D templates are as this solution is entirely a library solution where as numpy uses mountains of C code glued to Python. So, I think that this can be more powerful than numpy, as this fits naturally into the rest of your code base and can work efficiently with any range based code already written.

I couldn't easily find how to make the module work with allocators. IMO combining this module with std.experiemtal.allocator should be possible. And if it is already possible, there should be tests for documentation and validation.