$include_dir="/home/hyper-archives/ublas/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [ublas] Patch/proposal for overloading operator * in ublas
From: Gunter Winkler (guwi17_at_[hidden])
Date: 2009-09-09 17:11:41
Rutger ter Borg schrieb:
> K.M.A.Chai_at_[hidden] wrote:
>
>   
>>     That said, it will be nice if ublas can be easily extendable. A lot of
>> people has been asking about overloading * in ublas. However, currently
>> ublas is pretty greedy: it tries to handle all of operator*, so that
>> extending operator* in a naive way (by the end user) will lead to the
>> compiler complaining. Attached are two patches to make ublas less greedy
>> in this aspect.
>>     
>
> I agree that uBLAS should be extensible -- e.g., a bit like a toolbox in 
> Matlab and GLAS.
>
> For this to work, one would need to easily export and extend the domain 
> specific language (DSL). Perhaps it is a good time to let Boost.Proto handle 
> uBLAS' expression machinery -- is has the facilities we're looking for.
>
>   
But this raises again the question: Why do we need so many different
linear algebra libs? Shouldn't we simply freeze uBLAS and slowly switch
to MTL4 (http://www.osl.iu.edu/research/mtl/mtl4/, which is already
quite powerful and uses state of the art programming methods)? The
complete redesign of the template machinery would take weeks of a full
time developer - however there is no one right now who can take this
task. There is even a good lib for small matrices available:
http://tvmet.sourceforge.net/
> What would be nice is to be able to work with expression trees. In this case 
> I'm referring to Proto's semantic actions, or expression transformation. 
> E.g., rewrite an expression to make use of BLAS calls (or, some other 
> "backend"). Pattern matching on the expression, rewrite, and transparently 
> an other expression is used. All in compile time.
>   
The automatic mapping to blas calls and operations on expression tree
would be a real "exciter".
mfg
Gunter