$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: jhrwalter (walter_at_[hidden])
Date: 2001-12-08 07:28:30
--- In boost_at_y..., Toon Knapen <toon.knapen_at_s...> wrote:
> jhrwalter wrote:
[snip]
> > compressed_array has a range insert member. Doesn't it suffice?
>
> parially. The last instruction here is also a std::sort. So if I
want to
> sort the whole thing only once I have to do only 1 call to the
range
> insert to insert the whole structure. This is doable but I would
need to
> allocate first a vector in which I will build up the coordinates
of
> all non-zeroes. Next I'll do a range insert. During the copy, space
to
> store the coordinates is allocated twice (once in my vector, once
in the
> compressed_array).
Ok, I understand the problem. May be we'll have to analyze, if and
how it's possible to build a compressed_array with deferred sorting.
BTW aren't others working on array containers with a std::map like
interface already?
> In the compressed_array, you store the structure along with the
content
> of the matrix (because it's a C-array of std::pair< index, value
>).
> In my (very limited) matrix lib, I seperated both so that I could
first
> create the structure and then create a matrix with the given
structure.
> Whereas maybe the latter approach offers more flexibility, I guess
it
> limits cache performance. I don't know if you already looked at
cache
> behaviour or what inspired storing the std::pair's in the C-array.
No, we didn't analyze cache behaviour. The design simply fitted well
with the existing dense matrices.
[snip]
> > Sorry, you've lost me. Are you talking about extending/changing
> > existing sparse matrix formats or about new CRS and CCS formats
here?
> Sorry, my explanation was not very clear. The bottom line though is
>
> that a sparse matrix need to build up in several steps :
>
>
> First I need to gather all the indices where a non-zero will be
stored.
> While building up this list, I will not sort the entries, just
push_back
> them in some vector.
Ok. Something like a vector<std::pair<std::size_t, std::size_t> >, if
I've understood it correctly?
> In a second step, I will sort all entries and format them in some
> specific way (COO, CSC, ... )
Ok. Here one can compress that vector<std::pair<std::size_t,
std::size_t> > also?
> In a third step, I create a sparse matrix (with the structure as an
> argument for its constructor) which will allocate space to store
the
> non-zeros for the indices known in advance.
Ok.
> Again, here I seperate structure from the values contained by the
> matrix. Maybe it is not optimal to store the structure and values
> seperatly : in memory, the indices can be far from their
corresponding
> value which may destroy cache-performance.
But it should be possible to get the Fortran storage layout. So may
be one could try to specialize to external functions in this case
also.
Regards
Joerg