Re: [ublas] [bindings] naming for sparse matrices

Subject: Re: [ublas] [bindings] naming for sparse matrices
From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2010-02-08 17:33:52

Rutger ter Borg wrote:
> Thomas Klimpel wrote:
> > 
> > Well, if you are sure that you like it, why not.
> >
>
> I'm not that sure, let's look at the alternative:
>
> * keep begin_value as is, to iterate over all values of any container. Works 
> for all containers using single value array, and also for the sparse stuff. 
> Will need some specialized iterators (if ever) for mapped sparse stuff.

This sounds reasonable.

> * begin_major_first_nonzero? (I don't like start here).. or something else?

The most common name for this array is "row_ptr" / "col_ptr". But a c/c++ programmer will have an uneasy feeling about the "ptr". UBlas calls it "index1_data_", mtl4 calls it "starts", glas calls it "compressed_index_" and eigen2 calls it "m_outerIndex".

>   begin_minor_index: I like this one, as you describe (or 
> begin_index_minor)?

How about "begin_index_minor" and "begin_compressed_index_major"?

>
> * begin_tuple, end_tuple. Used for mapped sparse stuff (coordinate stuff), 
> nice in combination with some specialized iterators for other data 
> structures.

I'm not sure we should support the mapped stuff at all. I don't think that elementary matrix operations can be implemented efficiently with this storage format. So it would only be useful during matrix assembly. And I don't think that mtl4, glas or eigen2 offer the mapped stuff at all (but I could be wrong).

>
> * begin_diag_main, begin_diag_super, begin_diag_sub?
>

I guess the tridiagonal format is a special case of a special banded format. This may be best realized by a "banded_view" over a normal matrix, like mtl4 offers. But I would have to study both ublas and mtl4 more in detail to see whether their offering for banded matrices supports this. Without support for tridiagonal matrices in the existing matrix libraries, the current bindings for tridiagonal matrices might be not so bad after all.

I tried to implement the sparse matrix stuff this weekend, but got buried in studying umfpack, ublas, glas, mtl4, eigen2 and the bindings themselves to learn how this would work. I didn't even had time to look into SuperLU and MUMPS in more detail. And I studied the tag-dispatching structure of the new traits system, and realized that the sparse stuff will also have to add new tags for its commands. The yet to be invented names for the new tags finally stopped me from doing any real work at all...

And the coordinate_matrix format seems actually quite tricky to handle (in the case of umfpack), because the "sort" method must be executed, and the "compressed_index_major" array must be build and stored (and its lifetime must be "managed").

(Can we remove "has_rank.hpp" and "min_rank.hpp"? How do "begin_row"/"begin_column" actually work? I haven't understood how the row index is passed to the command.)

Regards,
Thomas