[Issue 3241] New: Limitations of array operations with parenthesis

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=3241

           Summary: Limitations of array operations with parenthesis
           Product: D
           Version: 1.043
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody at puremagic.com
        ReportedBy: baryluk at smp.if.uj.edu.pl


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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------