Boost logo

Ublas :

Subject: Re: [ublas] Patch/proposal for overloading operator * in ublas
From: Rutger ter Borg (rutger_at_[hidden])
Date: 2009-09-11 03:32:36

K.M.A.Chai_at_[hidden] wrote:

> (Apologies for the multiple posts; I've got the subject header wrong so
> that it doesn't thread properly in the previous post).

I thought this had to do with the mail reader sending "references" tags :-)

> I beg to diff.

Good :-)

> I think pretty printing is pretty individual. Currently, I
> use an sed script to transform the ublas outputs on the console to
> something I can understand easily.
> For serialization, the use of matlab mat formats, boost serialization,
> hdf5 or simply csv/ascii is also quite application specific. I think the
> proper place is to overload ostream<< and istream>> for individual
> formats.

Or, by introducing Matlab and HDF5 archives for Boost.Serialization. Of
course, for any traits-supported matrix type.

> That said, would it be worthwhile to have a set of io-manipulators for
> ublas outputs? For example, to specify if the row delimiter is "),(" or
> '\n'. I can put in some patch for this from my previous code if there is
> interest.
>> * support mixed-memory models (RAM / RAM of GPU board)
>> * support distributed / parallel containers
> I think these are pretty hard to achieve in C++, given that the semantics
> of this is still to be define properly in the language. For example, we
> have to wait until C++0x to have multi-threading in the language/library.
> Hence, I think the proper place for this is in vendor supplied libraries,
> or in specially tailored plugins.

I am quite content with Boost.Thread, it will probably be a matter of
replacing boost:: with std:: after a while. Perhaps what I was saying, is
that support for such memory models should be in a traits system. Please see

for what I meant (host/device semantics).

>> 2) Take the uBLAS expressions are they are after some revisions that have
>> been suggested. Provide a reference implementation for these expressions.
> Is ublas not a reference implementation?

At the moment, ublas expressions and its containers are intertwined. E.g.,
in matrix.hpp, there are references ublas' matrix_expressions. What I was
proposing, would be to strip that out of the containers, introduce a new
layer: the traits mechanism, and make expressions work with the traits.
Benefit: the containers are separated from the expressions -- any traits-
compatible container can be used.

> the usebindings facility in the library I've posted previously at
> is a humble
> attempt at reparsing ublas expressions. It is pretty messy, and would
> properly be neater if ublas has been designed for such "peeking into
> expression tree" in mind.

Cool, will look into it.

> My view is that ublas is a library to access BLAS convienently in C++, and
> not a general matrix manipulation library. In this light, I think ublas
> does a rather good job.

Sure. On the other hand, uBLAS is reaching its flexibility limits.

> Also, other people on the list might be interested in FLENS at

Thanks for the link. Again, their own containers... :-(