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

Subject: Re: [ublas] [bindings] naming for sparse matrices
From: Rutger ter Borg (rutger_at_[hidden])
Date: 2010-02-02 03:24:47

Thomas Klimpel wrote:
> 
> If you want to do all the work :-)
> I could also try to write it and do the necessary adjustments.

Even better :-).. Should be a matter of recursive file search-replace.

>> Do we need an index_type<M>::type?
> 
> I don't know, but probably yes. In case the index_type of umfpack/mumps is
> not identical to index_type<M>::type, it looks like some conversion must
> be done.

The question is: can that conversion be done? I.e., I don't think 64/32 bit 
integers can be mixed? (unless it is configurable in umfpack/mumps?).

>>
>> the contents of these arrays depend on the data structure.
> 
> Well, if you are sure that you like it, why not. What is the type of
> "*begin_array1( ... )"? Wouldn't it be better not to mix "index" and
> "numerical" data? The tridiagonal matrices requested by lapack are not
> always "true" tridiagonal matrices, because the off-diagonal sometimes has
> n-elements instead of n-1.

The type of *begin_array1( ... ) depends on the data structure, which may be 
an associative array containing tuples or plain value data in case of a 
linear array. Given the meta-functions has_linear_array<T>, etc., it should 
be rather easy to create a meta-function returning the type of values in 
array N. 

But indeed, we will need a table that shows data structure versus how many 
arrays and what's in the arrays. This is different from the begin(...) and 
begin1(M,...) -- these give structure-interpreted iterators. begin_arrayN is 
just access to the underlying arrays part of the data structure.

The alternative would be to have at least 6 or 7 functions (versus, say, at 
most 3) to dispatch to the adaptors. The function_nameN can be nicely 
dispatched with some macro trickery already available.

Please let me know if I can be of assistance.

Cheers,

Rutger