www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Language Idea #6892: in array ops, enable mixing slices and random

reply Guillaume Piolat <notthat email.com> writes:
General idea
============

Currently arrays ops express loops over slices.

     a[] = b[] * 2 + c[]

It would be nice if one could mix a random access range into such 
an expression.
The compiler would have builtin support for random access range.


Example
=======

------------------------------>3---------------------------------------

import std.algorithm;
import std.array;
import std.range;

void main()
{
	int[] A = [1, 2, 3];
	
	// arrays ops only work with slices
	A[] += iota(3).array[];
	
	
	// Check that iota is a random access range
	auto myRange = iota(3);
	static assert( isRandomAccessRange!(typeof(myRange)) );
	
	
	// Doesn't work, array ops can't mix random access ranges and 
slices
         // NEW
	A[] += myRange[]; // whatever syntax could help the compiler
}

------------------------------>3---------------------------------------


How it could work
=================

     A[] += myRange[]; // or another syntax for "myRange as an 
array op operand"

would be rewritten to:

     foreach(i; 0..A.length)
         A[i] += myRange[i];


myRange should not be a range without "length".


Why?
====

Bridges a gap between lazy generation and array ops, now that 
array ops are reliable.
Allow arrays ops to take slice-like objects.


What do you think?
Feb 05
parent reply Meta <jared771 gmail.com> writes:
On Monday, 5 February 2018 at 17:35:45 UTC, Guillaume Piolat 
wrote:
 General idea
 ============

 Currently arrays ops express loops over slices.

     a[] = b[] * 2 + c[]

 It would be nice if one could mix a random access range into 
 such an expression.
 The compiler would have builtin support for random access range.


 Example
 =======

 ------------------------------>3---------------------------------------

 import std.algorithm;
 import std.array;
 import std.range;

 void main()
 {
 	int[] A = [1, 2, 3];
 	
 	// arrays ops only work with slices
 	A[] += iota(3).array[];
 	
 	
 	// Check that iota is a random access range
 	auto myRange = iota(3);
 	static assert( isRandomAccessRange!(typeof(myRange)) );
 	
 	
 	// Doesn't work, array ops can't mix random access ranges and 
 slices
         // NEW
 	A[] += myRange[]; // whatever syntax could help the compiler
 }

 ------------------------------>3---------------------------------------


 How it could work
 =================

     A[] += myRange[]; // or another syntax for "myRange as an 
 array op operand"

 would be rewritten to:

     foreach(i; 0..A.length)
         A[i] += myRange[i];


 myRange should not be a range without "length".


 Why?
 ====

 Bridges a gap between lazy generation and array ops, now that 
 array ops are reliable.
 Allow arrays ops to take slice-like objects.


 What do you think?
It's already possible, with only very slightly worse aesthetics: struct VecOp(T) { T[] arr; pragma(inline, true) T[] opOpAssign(string op: "+", Range)(Range r) { int i; foreach (e; r) { arr[i] += e; i++; } return arr; } } pragma(inline, true) VecOp!E vecOp(E)(return E[] arr) { return typeof(return)(arr); } void main() { import std.range: iota; int[] a = [1, 2, 3]; a.vecOp += iota(3); assert(a == [1, 3, 5]); } I'm not very good at reading assembly, so I have no idea whether it's comparable to doing `a[] += [0, 1, 2]`.
Feb 05
next sibling parent reply Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On Tuesday, 6 February 2018 at 02:14:35 UTC, Meta wrote:
 What do you think?
It's already possible, with only very slightly worse aesthetics:
[Good stuff] We can do better than that, though: import std.range, std.array, std.algorithm; struct Vec(Range) if (isInputRange!Range) { Range rng; this(Range value) { rng = value; } static if (!isInfinite!Range) { auto get() { return rng.array; } alias get this; } auto getRange(R2)(R2 other) { static if (isInputRange!R2) return other; else static if (isVec!R2) return other.rng; else return repeat(other); } auto opBinary(string op, R2)(R2 rhs) { return vec(rng.zip(getRange(rhs)).map!("a[0] "~op~" a[1]")); } auto opBinaryRight(string op, R2)(R2 lhs) { return vec(getRange(lhs).zip(rng).map!("a[0] "~op~" a[1]")); } auto opOpAssign(string op, R2)(R2 rhs) if (isForwardRange!Range) { auto rhsR = getRange(rhs); auto r = rng.save; foreach (ref e; r) { if (rhsR.empty) break; mixin("e "~op~"= rhsR.front;"); rhsR.popFront(); } return this; } } auto vec(Range)(Range r) if (isInputRange!Range) { return Vec!Range(r); } enum isVec(T) = is(T == Vec!U, U); unittest { import std.stdio; auto a = [1,2,3,4,5,6,7,8]; auto b = a.length.iota; auto c = recurrence!("a[n-1] + a[n-2]")(1, 1); uint[] result = a + b * c.vec; writeln(result); result.vec += result; } -- Simen
Feb 06
parent reply Guillaume Piolat <notthat email.com> writes:
On Tuesday, 6 February 2018 at 09:02:46 UTC, Simen Kjærås wrote:
 On Tuesday, 6 February 2018 at 02:14:35 UTC, Meta wrote:
 What do you think?
It's already possible, with only very slightly worse aesthetics:
[Good stuff] We can do better than that, though: [More good stuff]
The problem in your sample is that you turn a range into a new slice with .array (which is "alias this" also), and this allocates. Meta's solution brings slices into the range world instead (rather than ranges to array ops like originally proposed).
Feb 06
parent Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On Tuesday, 6 February 2018 at 12:13:22 UTC, Guillaume Piolat 
wrote:
 On Tuesday, 6 February 2018 at 09:02:46 UTC, Simen Kjærås wrote:
 On Tuesday, 6 February 2018 at 02:14:35 UTC, Meta wrote:
 What do you think?
It's already possible, with only very slightly worse aesthetics:
[Good stuff] We can do better than that, though: [More good stuff]
The problem in your sample is that you turn a range into a new slice with .array (which is "alias this" also), and this allocates.
Only if you assign it to an array. While it's not very well indicated in the above example, this also works, and does not allocate: unittest { auto a = [1,2,3,4,5,6,7,8]; auto b = a.length.iota; a.vec += b; } -- Simen
Feb 06
prev sibling parent Guillaume Piolat <notthat email.com> writes:
On Tuesday, 6 February 2018 at 02:14:35 UTC, Meta wrote:
 It's already possible, with only very slightly worse aesthetics:

 struct VecOp(T)
 {
     T[] arr;

     pragma(inline, true)
     T[] opOpAssign(string op: "+", Range)(Range r)
     {
         int i;
         foreach (e; r)
         {
             arr[i] += e;
             i++;
         }

         return arr;
     }
 }

 pragma(inline, true)
 VecOp!E vecOp(E)(return E[] arr)
 {
     return typeof(return)(arr);
 }
I'm not sure if this is equivalent to what I asked, but in the event it is, here is a thought. A fully featured VecOp could be part of druntime, and slices as array ops operands could be replaced by slice.vecOp by the compiler. If this vectorize well, this allow to remove array ops from the language. (However it seems to me array ops are recognized at the operator level but well)
Feb 06