www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - I'll be back soon

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Aug 07 2016
next sibling parent Chris <wendlec tcd.ie> writes:
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?
Aug 08 2016
prev sibling parent reply Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
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
Aug 09 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Aug 09 2016
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
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.
Aug 09 2016
prev sibling parent reply Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
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.
Aug 09 2016
parent reply Martin Nowak <code dawg.eu> writes:
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.
Aug 10 2016
next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Aug 10 2016
prev sibling next sibling parent jmh530 <john.michael.hall gmail.com> writes:
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)
Aug 10 2016
prev sibling parent reply Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
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.
Aug 10 2016
parent reply Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
Dne 10.8.2016 v 14:52 Ilya Yaroshenko via Digitalmars-d napsal(a):


 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.


But one can still do something like:

import nd = std.experimental.ndslice;
// now I can use nd.map which is not so different from ndMap
// and there could be some special module with aliases for those who are 
unable
// to use one char '.' extra :)
module std.experimental.ndslice.aliases;
alias ndMap = nd.map;
...


So I am against prefixes in func names like ndMap and so.
Aug 10 2016
parent Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Wednesday, 10 August 2016 at 18:38:15 UTC, Daniel Kozak wrote:

 Dne 10.8.2016 v 14:52 Ilya Yaroshenko via Digitalmars-d 
 napsal(a):


 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.


 But one can still do something like:

 import nd = std.experimental.ndslice;
 // now I can use nd.map which is not so different from ndMap
 // and there could be some special module with aliases for 
 those who are unable
 // to use one char '.' extra :)
 module std.experimental.ndslice.aliases;
 alias ndMap = nd.map;
 ...


 So I am against prefixes in func names like ndMap and so.



This approach has two issues:
1. This should be done for std.algorithm to, because its map 
would be broken anyway (import is not static).
2. Static import or nd.??? is not good for UFCS pipeline:


Slice!(3, C*) movingWindowByChannel(alias filter, C)
(Slice!(3, C*) image, size_t nr, size_t nc)
{
     return image
         .pack!1
         .windows(nr, nc)
         .unpack
         .transposed!(0, 1, 4)
         .pack!2
         .ndMap!filter
         .slice;
}
Aug 10 2016