Hello, I've been busy with a paper submission that has a deadline on Wednesday. There have also been some computer troubles along the way. After Wed I should be able to tend to the many open PRs (dog days of the summer these aren't! thanks for the many contributions!), look at GSoC progress, and tend to my own PRs. -- Andrei

On Sunday, 7 August 2016 at 18:25:45 UTC, Andrei Alexandrescu wrote:
> Hello, I've been busy with a paper submission that has a deadline on Wednesday. There have also been some computer troubles along the way. After Wed I should be able to tend to the many open PRs (dog days of the summer these aren't! thanks for the many contributions!), look at GSoC progress, and tend to my own PRs. -- Andrei

Jesus, do you never go on holiday?

On Sunday, 7 August 2016 at 18:25:45 UTC, Andrei Alexandrescu wrote:
> Hello, I've been busy with a paper submission that has a deadline on Wednesday. There have also been some computer troubles along the way. After Wed I should be able to tend to the many open PRs (dog days of the summer these aren't! thanks for the many contributions!), look at GSoC progress, and tend to my own PRs. -- Andrei

Andrei, please approve ndslice.algorithm [1] names and addition.
1. https://github.com/dlang/phobos/pull/4652 --Ilya

On 08/09/2016 10:32 AM, Ilya Yaroshenko wrote:
> On Sunday, 7 August 2016 at 18:25:45 UTC, Andrei Alexandrescu wrote:
>> Hello, I've been busy with a paper submission that has a deadline on
>> Wednesday. There have also been some computer troubles along the way.
>> After Wed I should be able to tend to the many open PRs (dog days of
>> the summer these aren't! thanks for the many contributions!), look at
>> GSoC progress, and tend to my own PRs. -- Andrei
>
> Andrei, please approve ndslice.algorithm [1] names and addition.
> 1. https://github.com/dlang/phobos/pull/4652 --Ilya

I see you use the "nd" prefix for algorithms, did you consider just distinguishing via package? -- Andrei

On Wednesday, 10 August 2016 at 01:11:52 UTC, Andrei Alexandrescu wrote:
>
> I see you use the "nd" prefix for algorithms, did you consider just distinguishing via package? -- Andrei

There was quite a bit of discussion about this on the pull request. The issue was that map and ndMap would have different behavior for an ndslice.

On Wednesday, 10 August 2016 at 01:11:52 UTC, Andrei Alexandrescu wrote:
> On 08/09/2016 10:32 AM, Ilya Yaroshenko wrote:
>> On Sunday, 7 August 2016 at 18:25:45 UTC, Andrei Alexandrescu wrote:
>>> Hello, I've been busy with a paper submission that has a deadline on
>>> Wednesday. There have also been some computer troubles along the way.
>>> After Wed I should be able to tend to the many open PRs (dog days of
>>> the summer these aren't! thanks for the many contributions!), look at
>>> GSoC progress, and tend to my own PRs. -- Andrei
>>
>> Andrei, please approve ndslice.algorithm [1] names and addition.
>> 1. https://github.com/dlang/phobos/pull/4652 --Ilya
>
> I see you use the "nd" prefix for algorithms, did you consider just distinguishing via package? -- Andrei

I don't think this is good for users. algorithm and ndslice.algorithm are used together in practice, for example `ndEach!swap(a, b);` We have few workaround for distinguishing via package: renaming, static import. But I consider that this always should work:

import std.range;
import std.algorithm;
import std.experimental.ndslice;

The reason is that users from math world in most of cases want to write small scripts fast and without knowing all language details. This is why Go is so popular comparing with D, thought. Go is smaller and simpler to learn and.

In addition, most of functions has very different API comparing with their prototypes from std.algorithms: multiple dimensions, multiple tensors, selection type, plus ndFind accepts static array as the first argument.

On Wednesday, 10 August 2016 at 05:49:55 UTC, Ilya Yaroshenko wrote:
> In addition, most of functions has very different API comparing with their prototypes from std.algorithms: multiple dimensions, multiple tensors, selection type, plus ndFind accepts static array as the first argument.

Overloads from different modules don't conflict when it's not possible to one of them. So if all of ndslice.algorithm functions only work with ndslices, and none of std.algorithm functions work with ndslices, you're fine.
I'd even consider forwarding std.algorithm.searching.find to ndslice.algorithm.find a better solution than adding awkward prefixes that look like we're using C.

I haven't yet used ndslice much though.

On Wednesday, August 10, 2016 10:33:11 Martin Nowak via Digitalmars-d wrote:
> On Wednesday, 10 August 2016 at 05:49:55 UTC, Ilya Yaroshenko
>
> wrote:
> > In addition, most of functions has very different API comparing with their prototypes from std.algorithms: multiple dimensions, multiple tensors, selection type, plus ndFind accepts static array as the first argument.
>
> Overloads from different modules don't conflict when it's not
> possible to one of them. So if all of ndslice.algorithm functions
> only work with ndslices, and none of std.algorithm functions work
> with ndslices, you're fine.
> I'd even consider forwarding std.algorithm.searching.find to
> ndslice.algorithm.find a better solution than adding awkward
> prefixes that look like we're using C.
>
> I haven't yet used ndslice much though.

I haven't really looked at ndslice yet, so maybe it makes more sense in its case than it does normally, but putting prefixes on functions like that seems like a serious code smell. Part of the reason that have a module system like we have is to be able to distinguish and separate functions that have the same name.

- Jonathan M Davis

On Wednesday, 10 August 2016 at 10:33:11 UTC, Martin Nowak wrote:
>
> Overloads from different modules don't conflict when it's not possible to one of them. So if all of ndslice.algorithm functions only work with ndslices, and none of std.algorithm functions work with ndslices, you're fine.
> I'd even consider forwarding std.algorithm.searching.find to ndslice.algorithm.find a better solution than adding awkward prefixes that look like we're using C.
>
> I haven't yet used ndslice much though.

Below is from the pull request. The nd functions are slightly different and someone might want to use the std.algorithm behavior with ndslices.

Original matrix

0 1 2
3 4 5
6 7 8

map for 2D case

The result is random access range.

fun(0 1 2)
fun(3 4 5)
fun(6 7 8)

ndmap for 2D case

The result is 2D slice, all operations on slices can be used.

fun(0) fun(1) fun(2)
fun(3) fun(4) fun(5)
fun(6) fun(7) fun(8)

On Wednesday, 10 August 2016 at 10:33:11 UTC, Martin Nowak wrote:
> On Wednesday, 10 August 2016 at 05:49:55 UTC, Ilya Yaroshenko wrote:
>> In addition, most of functions has very different API comparing with their prototypes from std.algorithms: multiple dimensions, multiple tensors, selection type, plus ndFind accepts static array as the first argument.
>
> Overloads from different modules don't conflict when it's not possible to one of them. So if all of ndslice.algorithm functions only work with ndslices, and none of std.algorithm functions work with ndslices, you're fine.
> I'd even consider forwarding std.algorithm.searching.find to ndslice.algorithm.find a better solution than adding awkward prefixes that look like we're using C.
>
> I haven't yet used ndslice much though.

This is true for find, but not true for other algorithms, because of two reasons:

1. std.algorithm works with ndslices because ndslices is random access ranges composed of n-1-dimensional elements.
2. most of algorithms are super-templates:
 a. template map(fun...)
 b. template ndMap(fun...)
so they would not work with the same namespace if names are identical.