Subject: Re: [ublas] Patch/proposal for overloading operator * in ublas
From: Jesse Perla (jesseperla_at_[hidden])
Date: 2009-09-10 08:15:33
On Thu, Sep 10, 2009 at 2:31 AM, Rutger ter Borg <rutger_at_[hidden]> wrote:
> Gunter Winkler wrote:
> > 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)?
Is MTL4 the clear successor to ublas with the intention of entering boost?
If so, maybe this is the way to go. And maybe MTL4 is close enough to being
ready. But I think that most people out there would be happy with a library
they can stick with for 5-10 years rather than getting the latest and
Rutger: What do you think is involved in getting the numeric traits for
MTL4? Do you think that the bindings might just "work" after that?
> > 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/
> The problem I have is not that there are different matrix libraries, but
that they never interoperate. I have both small and large matricies and
often need to multiply them... and what if I want to write generic
operations that work on both of them?
> After severals years of struggling with these libs, I've learnt that
> not one answer :-). All of them seem to want to do too much: provide the
> containers, expressions, and algorithms.
> IMHO, a better road would be the following....
Gunter: You are certainly correct, there will never be one matrix library
to rule them all.
But I think that most users would be happy with a default solution that is
good enough, and has the semantics they require (i.e. a reasonable
equivalent to matlab minus the algorithms). As far as I understand it, that
is what GLAS provides: A way to have a standard expression template
interface to various backends.
So, your road sounds like the right approach if ublas is to be kept modern,
but a lot of work. If ublas is a project in stasis, then perhaps your
instinct to freeze ublas and focus time on supporting MTL is the right one.