Boost logo

Boost :

Subject: Re: [boost] linear algebra library... again
From: DE (satan66613_at_[hidden])
Date: 2010-02-03 13:51:57


on 02.02.2010 at 23:20
 Rutger ter Borg wrote :
> Helo Pavel,

> I've taken a look at your documentation, but I guess my original question
> still stands: how does it complement uBLAS? All I can find is the addition
> of an overload for operator*, for which patches are available for uBLAS, and
> quite a smaller number of types of containers. What's in it for us?
to make long story short, i tried to eliminate the disadvantages (in
my opinion) of ublas and further advance the concept of c++ linear
algebra library.

unswering your question: i (re)designed the core of the lib so both
any number of containers, concepts and algorithms could be introduced
easily and intagrated seamlessly.

the complement part is that the user may choose between ublas and
natural notation linalg lib (such as this one).

some comparison to ublas:
it's hard for me to quickly inspect ublas documentation because i'm
used to the doxygen style documentation (or qt style to which doxygen
is similar).
as far as i can tell now the lib i propose provide a broader variety
of concepts such as shape of the matrix (rectangular. symmetric etc.).
this implies that a product of symmetric matrix is symmetric and so on.

  matrix<double, symmetric> m1, m2, m;
  //...
  m = m1*m2;

or you can provide different implementations of a particular operation
for different shapes so the user need not write

  process_symmetric(m);

but only

  process(m);

in general i did my best to provide very strict relationships and
interface so that nonsensical code will not compile at all.
additionally i tried to make the generic handling of all that concept
combinations as easy as possible.

furthermore vectors can be implicitly converted to matrices depending
on their orientation (column/row) like

  m = v;
or
  m = transpose(v1)*v2; //here matrix multiplication is involved

which is pretty useful i think.
  

-- 
Pavel

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk