[boost] Re: uBLAS and expression templates

From: Michael Stevens (support-1_at_[hidden])
Date: 2002-06-30 19:24:27

>
>
>From: "Benedikt Weber" <weber_at_[hidden]>
>
>Joerg
>
>>> It's a proven (but not well known ;-) technique to reintroduce
>>> temporaries at the right places into the expression, i.e. writing A *vector
>>    
>>
>>> (B * v).
>>    
>>
>I am glad there is at least a possibility to force the creation of a
>temporary. However, the user should not have to be concerned about such
>details. I never did anything with expression templates and I only recently
>read about them in the context of the Spirit parser. However, I think it
>should be possible to change the design so a temporary is automatically
>introduced where appropriate (say for the prod() functions). I urge you to
>think about a possibility to change that. It would be a real benefit for the
>library.
>
Benedikt's discussion regarding the evaluation complexities is very 
thought provoking. However automatically introducing temporaries would 
be a VERY bad thing. I say this for four reasons:
    a) The semantics of expression evaluation need to be clear and well 
defined. This is important to me, as I need to know the complexity and 
likely numerical accuracy of the result. Certainly uBLAS with ET 
certainly has very different semantics (and syntax) then without ET. 
Infact they seem to be two extremes of the possible stratergies. Both 
Benidict's points and David's worries regarding changes to template 
matching are relvant here.
I believe uBLAS's ET semantics are that the expression is evaluated as a 
WHOLE. That is each element of the result is computed using a complete 
expression formed from all the element on which it depends. Correct me 
if I am wrong here! Certainly it is wrong to think about various left or 
right associative interpretations of prod in this context.
I believe this matches my expectation for clear and well definied 
semantics. I cannot think of a way to automatically add temporaries that 
would not muddle this horribly.
    b) There is no "Best" solution to introducing temporaris. They vary 
in complexity and numerical accuracy.
    c) There are simple ways to explicity define when you want a a 
temporary. Either use more then one expression OR add explict constructors.
    d) The temporaries would inevitably be allocated from the heap. My 
experience with embedded programming makes we object to anything using 
the heap without my explict consent!

>>> Yes, I'm currently thinking about changing the interface for prod() to make the above problem more clear.
>>    
>>
I'm fascinated to think what you could have in mind here.

Michael