On Saturday, 22 June 2013 at 00:07:40 UTC, Timothee Cour wrote:
On Fri, Jun 21, 2013 at 4:14 PM, Timothee Cour
<[email protected]>wrote:
On Fri, Jun 21, 2013 at 4:02 PM, Ali Çehreli
<[email protected]> wrote:
On 06/21/2013 03:57 PM, Diggory wrote:
On Friday, 21 June 2013 at 22:56:04 UTC, Andrei Alexandrescu
wrote:
On 6/21/13 3:55 PM, Andrei Alexandrescu wrote:
On 6/21/13 3:45 PM, Timothee Cour wrote:
I'd like to support N-ary map, ie std.algorithm.map that
takes 1 or
more
ranges as arguments and operates lazily on those.
You can use "zip" from std.range.
Timothee specifically said that he is trying to avoid zip: :)
> before:
> zip(a,b).map!(u=>absDiff(u[0],**u[1])).reduce!fun;
> after:
> map!absDiff(a,b).reduce!fun;
Ali
also works great with string lambdas:
eg: dotproduct:
before:
zip(u,v).map!"a[0]*a[1]".reduce!"a+b";
after:
map!"a*b"(u,v).reduce!"a+b";
=> clearer, and provides more room for optimizaton
actually the version without the proposed N-ary map is even
worse, because
zip uses StoppingPolicy.shortest by default (which i find weird
and
contrary to D's safe by default stance):
here's the (corrected) dotproduct:
before:
zip(StoppingPolicy.requireSameLength,u,v).map!"a[0]*a[1]".reduce!"a+b";
after:
map!"a*b"(u,v).reduce!"a+b";
i think it's a clear improvement in terms of clarity (and again,
optimizations possible).
Would
map!"a*b"(u,v).reduce!"a+b";
be the preferred behaviour to implement a dot/scalar-product for
two fixed-dimensional vectors u and v, given that they all
implement the required operator overloads opRange/opSlice?
