
Ublas : 
Subject: Re: [ublas] [bindings] naming for sparse matrices
From: Rutger ter Borg (rutger_at_[hidden])
Date: 20100202 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 searchreplace.
>> 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 offdiagonal sometimes has
> nelements instead of n1.
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 metafunctions has_linear_array<T>, etc., it should
be rather easy to create a metafunction 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 structureinterpreted 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