|
|
Ublas : |
Subject: Re: [ublas] poll: what's your uBLAS I/O usage ?
From: Rutger ter Borg (rutger_at_[hidden])
Date: 2010-06-01 10:02:17
> Gunter Winkler <guwi17 <at> gmx.de> writes:
>> I'd like using the serialization this way (or using the funny "&"
>> notation). I see a the big advantage, that it is a) easy to provide a
>> working serialization for each uBlas container and b) easy to provide
>> different format. One could even imagine to provide a "console_archive"
>> for pretty printing matrices to std::out.
Guys, please keep in mind that, at least for the default archives, (Boost.)
serialization is not aimed at enabling hand-editing of files, or aimed at
reading files generated by other program(s). There are numerous examples of
posts on the user/devel mailing lists about this going wrong.
Perhaps Spirit's Qi/Karma could be used for external file parsing /
generation? (Or, to implement serialization archives). There's even a (quite
easy to follow) matrix-example in the Karma docs if I remember correctly.
> 4) You can see how I setup a few of the specializations here. A few
> questions about the bindings:
> a) Am I using the right metafunctions for the specializations? (matio
> seems to require contiguous row_major memory)
>
> b) How do I get the begin() and end() pointers to the data when using
> matrices row_major and column_major? I figured out begin() for vectors but
> was confused for matrices.
>
> c) Are there any tricks/utilities for converting the storage orderings
> from column to row major? I could do a transpose, but how can you do it
> in a data structure independent way?
>
> d) On a similar note, are there utilities to help with non-contiguous
> structures getting into a chunk of contiguous memory? If so, then these
> could be specialized for other than linear_array
>
a) definitely the right metafunctions. Perhaps not restrictive enough yet,
as the provided data may be a range / slice / view? I.e., a linear_array
doesn't guarantee that the object modeled uses that memory in a contiguous
way. For this, you could use the stride_*() and size_*() meta-functions.
b) we have begin_value and end_value which work for any container, but, in
case of a view, may result in too much data. begin() and end() work for
(strided) vectors, but isn't implemented yet for matrices (there's some work
remaining to do on the iterators). Please see bindings/begin, bindings/end,
bindings/detail/linear_iterator for most of the stuff. Feel free to
contribute :-)
c) there is no algorithmic support for doing in-place transpose besides
those in lapack/aux. Is this what you're asking? There's the trans()
function, of course (which allows mutable access).
d) definitely, for sparse structures, just use begin_value/end_value for the
value data and have a look at the begin/end_index_* stuff for access to
different styles of index arrays
HtH,
Cheers,
Rutger