Can we fix reverse operator overloading (opSub_r et. al.)?

[BCS]

Hello Rainer,

> BCS wrote:
> 
>> Reply to Rainer,
>> 
>>> 2. Expression-level optimization is the compiler's job, not the
>>> programmer's.
>>> 
>> Some (many?) of the interesting optimizations that can be applied to
>> expressions with overloaded operators are not algebraic in nature.
>> 
> I'm not sure what you mean by "algebraic" here, but...
> 

Algebraic optimizations would be optimizations that work by applying stuff 
you learned in algebra class.

>> Many of the use cases for operator overloading don't work if the
>> compiler is allowed to assume all the same identities it can for
>> scalars (e.g. the transitive identity doesn't hold for matrix math).
>> 
> The compiler shouldn't make any assumptions.  The compiler doesn't
> /need/ to make any assumptions, since the compiler has access to the
> actual code.  For example, take a simple vector expression, with
> 3-element vectors:
> 
[...]


Ok try another case:

y = a*b + c*a;

for scalers, the compiler can (and should) convert that 3 ops to 2:

y = a*(b+c);

for a matrix you can't. And I'm sure there are matrix cases where you can 
get improvements by doing algebraic manipulations before you inline that 
would be darn near impossible to get the compiler to figure out after you 
inline. 

>> Unless you wan to make a way for the programmer to both add and
>> remove expression level optimizations, and require an optimization
>> engine powerful enough to use them, you can't do optimization of
>> expressions with overloaded operators purely in the compiler.
>> 
> Why should the programmer need to give hints to the compiler when the
> compiler already has enough information to figure out how to optimize
> properly?

Because the compiler doesn't have enough information. I've tried to work 
with systems that are supposed to do math all by them selves. They didn't 
work well. Computational Algebra Systems don't work without hints.