Boost logo

Ublas :

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.