|
|
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
http://code.google.com/p/thrust/
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
> http://lists.boost.org/MailArchives/ublas/2009/08/3615.php 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
> http://flens.sourceforge.net/.
Thanks for the link. Again, their own containers... :-(
Cheers,
Rutger