RE: [boost] Operation representation in boost::etl

From: Matthew Hurd (matt_at_[hidden])
Date: 2003-11-25 07:29:37

> On Behalf Of Markus Werle
> Sent: Tuesday, 25 November 2003 10:02 PM
> Subject: [boost] Operation representation in boost::etl
> 
<snip> 
> Please comment and tell me what you think.

A boost::etl would be a lovely thing to see.  Such technology is beyond me
so I wish you well, but I would like to offer some comment.  (A lack of
understanding rarely stops me opening my mouth)

More than two operands would be a very good thing.  Representing such common
operations that you might put such a library to use with respect to, such
as: 

  *  DGEMM  performs one of the matrix-matrix operations
  *
  *     C := alpha*op( A )*op( B ) + beta*C,
  *
  *  where  op( X ) is one of
  *
  *     op( X ) = X   or   op( X ) = X',
  *
  *  alpha and beta are scalars, and A, B and C are matrices, with op( A )
  *  an m by k matrix,  op( B )  a  k by n matrix and  C an m by n matrix.

would be good.  I can imagine such a library being extended to refactoring
and rewriting expression trees with such multi operand targets in mind
directly or perhaps just indirectly.  

I worry that the simple elegance of recursing down the expr children might
be a little more complicated if it is both children and a type list... but I
hardly understand it...

OTOH, whilst adding another level of indirection cures many a problem, in my
mind I want to go to the trouble of using a boost::etl because performance
matters dearly to me.  I suspect the cost might vary, for such an extra
level of indirection, quite a bit from compiler to compiler as many
compilers already struggle with optimizing simpler ETL structures, but you
may know better.  

So it may not be pragmatic...  only some benchmarks on a few platforms might
yield the true answer, but to do that you have to write it and then you
might as well leave in it to push vendors and for the niceties it may bring
as you might always use binary ops anyway.  Strikes me as worth doing as
some other boost libs have also gone down the track of including alternative
interfaces to see what real world use brings to table...

Also, it might be nice to build with something specific in mind to direct
the goals.  Perhaps there is some benefit boost::etl might bring to
boost::ublas.  It would be an interesting non-trivial proving ground,
thought you might be better off picking on something less large.

Any thoughts about how Daixtrose is different to POOMAs PETE?  

I see your manual is pretty much oriented to the math side of the equation.
I would be interested to see how a simple non numeric thing, like the string
concatenation I tried out a while ago, would lend itself you your lib.

Just $AUD 0.02 

Matt Hurd.