Boost logo

Ublas :

Subject: Re: [ublas] [bindings] naming for sparse matrices
From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2010-01-29 06:31:03


Rutger ter Borg wrote:
> I am looking for nice names for the sparse stuff. E.g.,
>
> begin_coord1( m ) // Coord iterator, works for *all* matrices
> begin_coord2( m ) // Coord iterator

Since we are dealing with matrices, there is not much too choice left with respect to terminology. We don't have the freedom to rename index/indices to coord/coords or coordinate/coordinates. (Of course we could do it, but it would just be wrong, in a certain sense.)

(I know that there are the storage format tags "compressed_t" and "coordinate_t", but these probably just refer to the corresponding ublas matrix types, and not to the underlying concepts. I think "coordinate_t" refers to a sparse matrix that is potentially stored totally unordered, while "compressed_t" gives at least an order guarantee for either the rows or the columns.)

The "xxx1" / "xxx2" is a question with more choice. In a certain sense, "xxx1" is an easy to understand abbreviation for "xxx_row" and "xxx2" an abbreviation for "xxx_column". More tricky is the tag "index<1>", because I think the leftmost element of a tuple is accessed via tuple.get<0>(), but the leftmost element of a pair is accessed via pair.first. The best way I see to avoid this is to not have "xxx<1>" / "xxx<2>" selection at all.

> (or begin_c1/begin_c2, or begin_i, begin_j?). Take these two functions, the
> begin_value, mix in a zip iterator, and you will get tuples
> ( i, j, a_ij )

I like begin_i, begin_j.

So what is still missing are names for the "compressed_t" stuff? The existing bindings use the following names:

    // index_pointer index1_storage()
    // - compressed column: array of column start locations
    // - compressed row: array of row start locations
    // index_pointer index2_storage()
    // - compressed column: array of row indices of nonzeros
    // - compressed row: array of column indices of nonzero

So what about "begin_start" instead of "index1_storage" and "begin_index" instead of "index2_storage"? No, that's too confusing. Less confusing might be "begin_major_start" and "begin_minor_index".

Don't misinterpret what I wrote as that I would be fixed on anything here. I just tried to understand the problem at least superficially, and give my first thoughts about it, so that the discussion can go on...

Regards,
Thomas