Array operations -- not actually so difficult

[Knud Sørensen]

I expect for the array operation in 2.0 is something like vectorization.
see http://www.all-technology.com/eigenpolls/dwishlist/index.php?it=10

Which allows you (in one line) to make multidimensional calculations on
an arbitrary number of multidimensional arrays, 
but it still allows you to read exactly which indexed is used 
and the exact calculation performed. 

The syntax don't generate temporary arrays 
and allow the compiler to freely reorder nested loops.

Also the compiler will be free to support for SSE? 
and GPUs in the future without your having to rewriting the
vectorization code.
 
I don't expect to see this in 1.0 I am just pointing out 
that the array operation you suggest here seems fare from 
my expectations for 2.0.

Knud
  

On Fri, 15 Dec 2006 10:40:16 +0100, Don Clugston wrote:

> Array operations are one of the very few 2.0 features that haven't made 
> it into 1.0. My experiments into expression templates suggest that it 
> might not be very complicated after all.
> 
> Consider something like a dot product,
> 
> real a[], b[], c[];
> real d = dot(a+b, c);
> 
> For performance, it would be better if the compiler actually *didn't* 
> evaluate a+b. Instead, that should compile to:
> 
> real sum = 0;
> for (int i=0; i<c.length; ++i) {
>       sum+=(a[i]+b[i])*c[i];
> }
> d=sum;
> 
> In fact, we could create a fantastic library implementation of array 
> operations with a tiny bit of syntactic sugar:
> instead of generating an error message for array operations, look for an 
> opXXX function, and treat it the same way the implicit array properties 
> work.
> ----------
> void opMulAssign(real [] a, real w)
> {
>      for(int i=0; i<a.length; ++i) { a[i]*=w; }
> }
> 
> void main()
> {
>      real b[] = [1.0L, 2, 3, 4];
>      b.opMulAssign(3.5); // OK.
>      b *= 3.5; // Fails with "Error: 'b' is not a scalar, it is a real[]"
> }
> ----------
> So the message to Walter is, support for array operations will not 
> require any change to the back end. They are just a bit of syntactic 
> sugar at the front end.