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.
>
> 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


## Guide for Slice/Matrix/BLAS contributors

1. Pay _unprecedented_ attention to functions to be
       a. inlined(!),
       b. `@nogc`,
       c. `nothrow`,
       d. `pure`.
    95% of functions will be marked with `pragma(inline, true)`. So, use
    _simple_ `assert`s with messages that can be computed at compile time.
    The goals are:
        1. to reduce executable size for _any_ compilation mode
        2. to reduce template bloat in object files
        3. to reduce compilation time
        4. to allow a user to write an extern C bindings for code based on `Slice`.

2. Do not import `std.format`, `std.string` and `std.conv` to format error
    messages.`"Use" ~ Concatenation.stringof ~ ", really ."` Why? Please,
    read [1] again.

3. Try to use already defined `mixin template`s for pretty error messaging.

4. Do not use `Exception`s/`enforce`s to check indexes and length. Exceptions are
    allowed only for algorithms where validation of an input data is
    significantly complex for user. `reshaped` is a good example where
    Exceptions are required. Put an example of Exception handing and workaround
    for function that can throw.

5. Do not use compile time flags for simple checks like transposition
    of a matrix. It is much better to have runtime matrix transposition.
    Furthermore, Slice provide runtime matrix transposition out of the box.

6. Do not use _Fortran_VS_C_ flags. They are about notation,
    but not about algorithm itself. To care about math world users add
    appropriate code example in the documentation. `transposed` / `everted`
    can be used for cash friendly code.

7. Do not use compile time power of D to produce dummy entities like
    `IdentityMatrix`.

8. Try to separate allocation and algorithm logic whenever possible.

9. Add CTFE unittests to new functions.

---

Update docs:
http://dtest.thecybershadow.net/artifact/website-7a646fdea76569e009844cdee5c93edab10980ca-87c7c7a1a6e59a71179301c54d012057/web/phobos-prerelease/std_experimental_range_ndslice.html

-- Ilya

On Wednesday, 18 November 2015 at 10:26:13 UTC, Ilya Yaroshenko wrote:
> On Wednesday, 18 November 2015 at 08:52:11 UTC, Robert burner Schadek wrote:
>> 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.
>
> I have added makeSlice, however this function can be easily implemented by user: allocate array -> pass array to `sliced`.
>
> updated docs http://dtest.thecybershadow.net/artifact/website-7a646fdea76569e009844cdee5c93edab10980ca-ce47155797f387348826317811c4af0c/web/phobos-prerelease/std_experimental_range_ndslice.html
> --Ilya

I spoke with Andrei over email and his opinion was that if this module makes any allocation that can't be avoided, then std.experimental.allocator should be integrated.

On Friday, 20 November 2015 at 19:21:45 UTC, Jack Stouffer wrote:
> On Wednesday, 18 November 2015 at 10:26:13 UTC, Ilya Yaroshenko wrote:
>> On Wednesday, 18 November 2015 at 08:52:11 UTC, Robert burner Schadek wrote:
>>> [...]
>>
>> I have added makeSlice, however this function can be easily implemented by user: allocate array -> pass array to `sliced`.
>>
>> updated docs http://dtest.thecybershadow.net/artifact/website-7a646fdea76569e009844cdee5c93edab10980ca-ce47155797f387348826317811c4af0c/web/phobos-prerelease/std_experimental_range_ndslice.html
>> --Ilya
>
> I spoke with Andrei over email and his opinion was that if this module makes any allocation that can't be avoided, then std.experimental.allocator should be integrated.

Great! Added to PR's TODO list :-)

On Friday, 20 November 2015 at 20:33:27 UTC, Ilya wrote:
> Great! Added to PR's TODO list :-)

This will be interesting because there is no defined idiomatic usage of std.allocator. I imagine std.range.ndslice will be the trend-setter for Phobos in this regard.

On 11/20/15 4:23 PM, Jack Stouffer wrote:
> On Friday, 20 November 2015 at 20:33:27 UTC, Ilya wrote:
>> Great! Added to PR's TODO list :-)
>
> This will be interesting because there is no defined idiomatic usage of
> std.allocator. I imagine std.range.ndslice will be the trend-setter for
> Phobos in this regard.

There's the persistent list example that I posted on dpaste a couple weeks back. I do expect things to evolve a bit before stabilizing.

BTW thanks Jack for reaching out via email.


Andrei

On Friday, 20 November 2015 at 21:23:40 UTC, Jack Stouffer wrote:
> On Friday, 20 November 2015 at 20:33:27 UTC, Ilya wrote:
>> Great! Added to PR's TODO list :-)
>
> This will be interesting because there is no defined idiomatic usage of std.allocator. I imagine std.range.ndslice will be the trend-setter for Phobos in this regard.

Slice is only a shell over a range/array. There is no reason to add any kind of counters or special stuff entities. All this idioms work out of the box because Slice holds an array. It is already works with std.container.array, and it will work with the future Array container based on allocators.

-- Ilya

On Friday, 20 November 2015 at 21:55:18 UTC, Andrei Alexandrescu wrote:
> On 11/20/15 4:23 PM, Jack Stouffer wrote:
>> On Friday, 20 November 2015 at 20:33:27 UTC, Ilya wrote:
>>> Great! Added to PR's TODO list :-)
>>
>> This will be interesting because there is no defined idiomatic usage of
>> std.allocator. I imagine std.range.ndslice will be the trend-setter for
>> Phobos in this regard.
>
> There's the persistent list example that I posted on dpaste a couple weeks back. I do expect things to evolve a bit before stabilizing.
>
> BTW thanks Jack for reaching out via email.
>
>
> Andrei

After playing with memory allocation I became convinced that ndslice package should not have any kind of memory allocation (except opCast to array) at least we will add allocators support to std.array. The most important function is std.array.array.

Out of the box user can do `auto slice = new int[2*3*4+n].sliced(2, 3, 4); //n>=0`.
The link below contains convenience functions in examples for `sliced`
1. `createSlice` creates an GC allocated slice
2. `ndarray` creates GC allocated ndarray copy of a slice
3.  `makeSlice` make slice with allocators

They are only examples and not a part of the API.

http://dtest.thecybershadow.net/artifact/website-20b34f54aaeb876b545bac1d34b954db15f0a237-0d1a48cd3d6cc5a31c97ba84a93229e4/web/phobos-prerelease/std_experimental_ndslice_slice.html#.sliced

--Ilya

On Monday, 16 November 2015 at 22:45:35 UTC, Jack Stouffer wrote:
> This is the start of the two week formal review

Friendly reminder that the review ends tomorrow.

On Sunday, 29 November 2015 at 20:53:43 UTC, Jack Stouffer wrote:
> On Monday, 16 November 2015 at 22:45:35 UTC, Jack Stouffer wrote:
>> This is the start of the two week formal review
>
> Friendly reminder that the review ends tomorrow.

The two week review is over. Thank you to everyone who commented here or on the PR. Of course, even though the review is over, you can still make comments on the GitHub PR up until it's merged.

9il, please let me know if you want to start the voting right away or wait until your list is completed.

On Tuesday, 1 December 2015 at 16:03:51 UTC, Jack Stouffer wrote:
> On Sunday, 29 November 2015 at 20:53:43 UTC, Jack Stouffer wrote:
>> On Monday, 16 November 2015 at 22:45:35 UTC, Jack Stouffer wrote:
>>> This is the start of the two week formal review
>>
>> Friendly reminder that the review ends tomorrow.
>
> The two week review is over. Thank you to everyone who commented here or on the PR. Of course, even though the review is over, you can still make comments on the GitHub PR up until it's merged.
>
> 9il, please let me know if you want to start the voting right away or wait until your list is completed.

Thank you, Jack!

I plan to check English text and add 4D example for image processing and 5D example for computer vision first. They should help users to imagine use cases.

Plus looks like we need comparison between D.Slice and numpy.ndarray. Slice is more flexible, faster and generalised comparing with ndarray. In the same time Slice has not problems with extensions like numpy dose (as you have already noted) and it has tiny (in LOC) implementation. I hope that examples and the comparison would be moved later to DBlog (D needs blog!) with detailed explanation by another author (I can be reviewer).