www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - array operation a[] + b[] not implemented??

reply Trass3r <un known.com> writes:
It is implemented in the runtime so why doesn't it work?


/***********************
  * Computes:
  *      a[] = b[] + c[]
  */

T[] _arraySliceSliceAddSliceAssign_f(T[] a, T[] c, T[] b)
...
...



void main()
{
	float[] a = [0.f, 0.5f, 1.0f, 1.5f, 2.0f, 2.5f];
	float[] b = [0.f, 0.5f, 1.0f, 1.5f, 2.0f, 2.5f];

//	float[] c = a[] + b[]; // <-- Array operation a[] + b[] not implemented
	float[] d = a[] * 4.f + 1.f;
	writeln(d); // <-- access violation when program is run
}
Jan 17 2010
parent reply Matti Niemenmaa <see_signature for.real.address> writes:
On 2010-01-18 00:42, Trass3r wrote:

 It is implemented in the runtime so why doesn't it work?


 /***********************
 * Computes:
 * a[] = b[] + c[]
 */

 T[] _arraySliceSliceAddSliceAssign_f(T[] a, T[] c, T[] b)
 ...
 ...



 void main()
 {
 float[] a = [0.f, 0.5f, 1.0f, 1.5f, 2.0f, 2.5f];
 float[] b = [0.f, 0.5f, 1.0f, 1.5f, 2.0f, 2.5f];

 // float[] c = a[] + b[]; // <-- Array operation a[] + b[] not implemented
 float[] d = a[] * 4.f + 1.f;
 writeln(d); // <-- access violation when program is run
 }


This is Bug 3066: http://d.puremagic.com/issues/show_bug.cgi?id=3066

Your code is invalid, since per the spec 
(http://www.digitalmars.com/d/1.0/arrays.html) array operations are 
valid only on the RHS of an assignment when there's a slice on the LHS. 
In your case, you're not performing an assignment at all, you're 
initializing, and array operations are not valid initializers.

To fix, preallocate and then perform the array op:

auto c = new float[a.length];
c[] = a[] + b[];
auto d = new float[a.length];
d[] = a[] * 4.f + 1.f;

-- 
E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi
Jan 17 2010
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Matti Niemenmaa (see_signature for.real.address)'s article

 On 2010-01-18 00:42, Trass3r wrote:

 It is implemented in the runtime so why doesn't it work?


 /***********************
 * Computes:
 * a[] = b[] + c[]
 */

 T[] _arraySliceSliceAddSliceAssign_f(T[] a, T[] c, T[] b)
 ...
 ...



 void main()
 {
 float[] a = [0.f, 0.5f, 1.0f, 1.5f, 2.0f, 2.5f];
 float[] b = [0.f, 0.5f, 1.0f, 1.5f, 2.0f, 2.5f];

 // float[] c = a[] + b[]; // <-- Array operation a[] + b[] not implemented
 float[] d = a[] * 4.f + 1.f;
 writeln(d); // <-- access violation when program is run
 }


 This is Bug 3066: http://d.puremagic.com/issues/show_bug.cgi?id=3066
 Your code is invalid, since per the spec
 (http://www.digitalmars.com/d/1.0/arrays.html) array operations are
 valid only on the RHS of an assignment when there's a slice on the LHS.
 In your case, you're not performing an assignment at all, you're
 initializing, and array operations are not valid initializers.
 To fix, preallocate and then perform the array op:
 auto c = new float[a.length];
 c[] = a[] + b[];
 auto d = new float[a.length];
 d[] = a[] * 4.f + 1.f;


As a side note, why isn't this allowed?  It seems like a perfectly reasonable
thing to have:

float[] c = a[] + b;

create a new array.  The semantics of what this would do are unambiguous, it
doesn't interact poorly (or at all) with the rest of the language in any way I
can
think of, the fact that it's not allowed is very surprising to newbies, and it's
highly convenient.  Why force people to write boilerplate code if there's no
tradeoff and you're not gaining anything in return?

Also, see bug 2549 (http://d.puremagic.com/issues/show_bug.cgi?id=2549).  If for
some reason we don't allow the creation of new arrays using array ops, we need
to
fix the error detection.
Jan 17 2010
next sibling parent reply Trass3r <un known.com> writes:
 As a side note, why isn't this allowed?  It seems like a perfectly  
 reasonable thing to have:

 float[] c = a[] + b;


Can't think of any point against it as well.
Add
	writeln(a[] + b[])
as a case where one would expect a new array to be created.



 Also, see bug 2549  
 (http://d.puremagic.com/issues/show_bug.cgi?id=2549).  If for
 some reason we don't allow the creation of new arrays using array ops,  
 we need to fix the error detection.


Yeah, it's strange that something like
	writeln(a[] * 4.f + 1.f);
or
	writeln(a[] * b[]);

gives the described access violation, while
	writeln(a[] + b[]);

yields Array operation not implemented.
Jan 17 2010
parent Don <nospam nospam.com> writes:
Trass3r wrote:

 As a side note, why isn't this allowed?  It seems like a perfectly 
 reasonable thing to have:

 float[] c = a[] + b;


 
 Can't think of any point against it as well.
 Add
     writeln(a[] + b[])
 as a case where one would expect a new array to be created.
 
 

 Also, see bug 2549 
 (http://d.puremagic.com/issues/show_bug.cgi?id=2549).  If for
 some reason we don't allow the creation of new arrays using array ops, 
 we need to fix the error detection.


 
 Yeah, it's strange that something like
     writeln(a[] * 4.f + 1.f);
 or
     writeln(a[] * b[]);
 
 gives the described access violation, while
     writeln(a[] + b[]);
 
 yields Array operation not implemented.


Array operations are still one of the most incomplete parts of the 
compiler. It's not hard to find bugs.
Jan 18 2010
prev sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
dsimcha wrote:

 As a side note, why isn't this allowed?  It seems like a perfectly reasonable
 thing to have:
 
 float[] c = a[] + b;
 
 create a new array.  The semantics of what this would do are unambiguous, it
 doesn't interact poorly (or at all) with the rest of the language in any way I
can
 think of, the fact that it's not allowed is very surprising to newbies, and
it's
 highly convenient.  Why force people to write boilerplate code if there's no
 tradeoff and you're not gaining anything in return?



Quoting Andrei in his "Short list with things to finish for D2" post 
(2009-11-19):


 * Loop fusion that generalizes array-wise operations. This idea of Walter is,
I think, very good because it generalizes and democratizes "magic". The idea is
that, if you do
 
 a = b + c;
 
 and b + c does not make sense but b and c are ranges for which a.front =
b.front + c.front does make sense, to automatically add the iteration
paraphernalia. 


If I read this correctly, what you're asking for will most likely happen.

-Lars
Jan 18 2010
parent reply Trass3r <un known.com> writes:
 Quoting Andrei in his "Short list with things to finish for D2" post  
 (2009-11-19):


 * Loop fusion that generalizes array-wise operations. This idea of  
 Walter is, I think, very good because it generalizes and democratizes  
 "magic". The idea is that, if you do
  a = b + c;
  and b + c does not make sense but b and c are ranges for which a.front  
 = b.front + c.front does make sense, to automatically add the iteration  
 paraphernalia.


 If I read this correctly, what you're asking for will most likely happen.


The question is, how much this is generalized with ranges. It needs to  
detect the special case of arrays and use vector operations then.
Jan 18 2010
parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Trass3r wrote:

 Quoting Andrei in his "Short list with things to finish for D2" post 
 (2009-11-19):


 * Loop fusion that generalizes array-wise operations. This idea of 
 Walter is, I think, very good because it generalizes and democratizes 
 "magic". The idea is that, if you do
  a = b + c;
  and b + c does not make sense but b and c are ranges for which 
 a.front = b.front + c.front does make sense, to automatically add the 
 iteration paraphernalia.


 If I read this correctly, what you're asking for will most likely happen.


 
 The question is, how much this is generalized with ranges. It needs to 
 detect the special case of arrays and use vector operations then.



Yeah, and most likely it will. But you can't expect every range to 
define the no-parameter opSlice() function, which means that the syntax 
for "range operations" should be just

   a = b + c;

It would then be pretty silly if we still had to use the

   a[] = b[] + c[];

syntax for the special case of arrays, so I assume that will change as well.

-Lars
Jan 18 2010