D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 3241 - Limitations of array operations with parenthesis
Summary: Limitations of array operations with parenthesis
Status: RESOLVED FIXED
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D1 (retired)
Hardware: Other Linux
: P2 normal
Assignee: No Owner
URL:
Keywords: rejects-valid
Depends on:
Blocks:
 
Reported: 2009-08-10 05:54 UTC by Witold Baryluk
Modified: 2014-04-18 09:12 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Witold Baryluk 2009-08-10 05:54:12 UTC
Example code:


void main() {
   int[8] a, b, c, d;

   //a[] += (a[] + 2*c[] - 3*b[]);      // ok
   a[] += 4*(a[] + 2*c[] - 3*b[]);  // not ok

   writefln(a);
}


commented line doesn't compile, giving error message:
v.d(7): Error: incompatible types for ((4) * (a[] + c[] * 2 - b[] * 3)): 'int' and 'int[]'
v.d(7): Error: 'a[] + c[] * 2 - b[] * 3' is not of arithmetic type, it is a int[]

the "4*" part can be manually propageted into the parenthesis (4*a[] + 4*2*c[] - 4*3*b[]), and this works, but why compiler can't do this?

There is even strange problem, for example with + operator:

a[] += 4+(a[] + 2*c[] - 3*b[]);

this gives also:
v.d(9): Error: incompatible types for ((4) + (a[] + c[] * 2 - b[] * 3)): 'int' and 'int[]'

but just removing parenthesis:

a[] += 4+a[] + 2*c[] - 3*b[];

produces correct code.

This problem is probably because array operation generator doesn't look into expressions in parenthesis, just check it types. So


a[] += 4+(a[] + 2*c[] - 3*b[]);

would be equivalent (if supported) to creating temporary:
int[8] temp = a[] + 2*c[] - 3*b[];
a[] += 4+temp[];

this would be suboptimal, because there will be double loop used in generated code, and excess coping.


AFAIK, BLAZE vector code generator allow such operations.

Because of this we can't also use pure mathematical function on arrays, 

a[] += sin(b[])*d[] + e[];

It would be awsome to have something like that. (given that sin is pure function).



BTW. I also noticed that spec doesn't say anything about custom types with operators overloaded. It probably just calls given operators in inner loop, but this operator probably creats own temporaries. Is there any optimalisations planed like allocation of this variables moved out of loop, or using opXAssign operators if compiler can optimalise it, somehow.

like:

a[] += b[]*d[]*e[] + 5;

=> // code gen

T t;  // T is struct or class, with some operators overloaded
foreach (i, ref v; a) {
  t = b[i]*d[i];
  t *= e[i];
  t += 5;
  a[i] += t;
}


I know compiler doesn't know which operator opMul or opMulAssing is more efficient, but given that it is mandatory to have a *= b, operate like a = a * b;, it doesn't metter.

This can be very powerfull substitute for "expression templates" from C++. (i know they are kind of voodoo and very powerfull, but we can mayby use only part of it). It is used for example in Blitz++ library. Actually we can already emulate them using our template magic, and is quite flexible.

Custom rules for array operations generator can be also usefull, but don't know how we would specify them. Mayby we should wait for D "macros" which will just allow us to investigate part of expression? This would make building custom AST using templates not needed.
Comment 1 Witold Baryluk 2010-01-31 10:10:59 UTC
Interesting. In 2.039+ this examples works and produces correct results.
Comment 2 Don 2010-04-28 00:09:54 UTC
Fixed DMD1.051 and 2.036.