Re: [boost] Re: ublas & custom containers? (2)

From: Joerg Walter (jhr.walter_at_[hidden])
Date: 2002-04-04 03:10:48

Hi Kresimir,

you wrote:

[snip]

> > You're right. I've changed the code in numerics::vector<>::clear and
> > numerics::matrix<>::clear to use std::fill instead. The change is
checked in
> > already.
>
> I noticed that you didn't change `vector_of_vector<>::clear()',
> which also calls `clear()' of inner array.

I missed that one. It doesn't seem to be correct, too.

> But it works anyway
> with `std::vector< std::vector<> >.  I am puzzled.

I'll look into this, thanks.

> > OTOH, our current
> > sparse_vector is interesting, because it can be used in conjunction with
> > std::map :-).
>
> Yes, I know. Even tried it ;o)
>
> > So two questions arise:
> > - should we eliminate the superfluous non_zero for sparse_vector?
>
> IMHO no. It's good to have uniform interface. But in the case of the
> `sparse_vector<>' some default value can be provided.

Ok.

> > - should we rename sparse_vector and/or compressed_vector?
>
> They seem fine to me.
>
> I have one more suggestion. There is
> `sparse_vector_of_sparse_vector<>' as a kind of sparse matrix.
> But I think there should also be `vector_of_sparse_vector<>'.
> At least in my field (structural analysis) sparse matrices always
> have at least one non-zero element in each row

Otherwise they would be rather singular ;-)

> -- therefore
> there is no need for outer vector to be sparse. And dense
> vector can provide faster access to rows. (I didn't peruse
> the code of `sp_vec_of_sp_vec'. Maybe it is already possible
> to use dense vector despite the name?)

No, sparse_vector_of_sparse_vector has only one array_type template
argument.

As the very_long_class_names should indicate, classes like vector_of_vector
and sparse_vector_of_sparse_vector were mainly intended as a proof of
concept, that one is able to adapt traditional C++ container of container
(like std::vector<std::vector<> >) as a matrix format.

Your proposed vector_of_sparse_vector is the only form of these, I could
vaguely imagine to use in a production environment. But wouldn't you really
prefer the traditional compressed storage format?

Best regards

Joerg