[boost] Re: Boost Mathematicians

From: Michael Stevens (Michael.Stevens_at_[hidden])
Date: 2004-07-06 04:44:50

Hi Jeremy,

On Tuesday 06 July 2004 02:51, Jeremy Graham Siek wrote:
>
> Although automagically inserting temporaries in non-trivial (especially
> since
> it must all be done with template meta-programming) I do not think it is
> a tar pit. Here is the simply heuristic that I used for MTL 3
> to decide where to put temporaries:
>
> 1. If an operation needs to read from an argument multiple times,
>      evaluate the argument eagerly into a temporary. For example,
>      a sparse matrix in compressed row format times the sum
>     of two vectors:
>
>     A * (x + y)
>
>    In this case, the (x + y) would be evaluated into a temporary before
>    evaluating the multiplication.
>
> 2. If an operation writes into its output in multiple passes, then
> perform
>     the operation in an eager fashion. For example, the sum
>     of a vector and the product of a sparse matrix in compressed column
>     format and a vector.
>
>    x + (A * y)
>
>    In this case, the (A * y) would be evaluated into a temporary before
>    evaluating the addition.

OK, this 'eager' evaluation logic seems sound to me. I assume it operates in a 
bottom up fashion on the expressions replacing operators with temporaries in 
either of the two cases.

Therefore providing a good heuristic to choose when a temporary seems 
possible. My problem is the exact choice of type for any temporary....

The mixing of sparse and dense is problematic. However your second example 
shows that we can get a hint from the types involved in many cases. But can 
this be done in the general case?

Let me make problem a little more generic. Even with uBLAS's weakly defined 
storage concept it is possible to parameterise A or y so it storage is 
off-line (on file). Although we know a temporary should be used we now need 
to make a choice of storage type.

In principle this is solvable (type traits, type promotion etc), particularly 
if storage type could be made orthogonal to other type parameters 
(dense/sparse, matrix/vector). This is however the generic "tar pit" I 
forsee.

Maybe I am being too sceptical in think that if the is no simple (for user to 
understand even if not to implement) generic solution we should not solve the 
base cases.

I guess I am also sceptical as without a deeper analysis of operators and 
types the user cannot know when temporaries will automagically appear. One 
big disadvantages of old OO C++ matrix libraries was the complete lack of 
control over temporaries. Simply stated I favour a strong correspondence 
between syntax and semantics.

All the best,
        Michael
-- 
___________________________________
Michael Stevens Systems Engineering
Navigation Systems, Estimation  and
                 Bayesian Filtering
    http://bayesclasses.sf.net
___________________________________