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;
}
