Re: Sparse matrix extension

[Alexis Tantet <alexis.tantet@gmail.com>]

I'm not sure I got your last point. I have the following situation in mind:

Start to construct a transition matrix in triplet format, adding one
element after another.
In this particular example, each element is one count of a transition
from (state, box, etc.) i to j,
so I add elements  (i, j, 1) to the triplet object, with possibly duplicates.
What happen to these duplicates in the binary tree?

Eventually, when I compress to CRS or CCS, I would like the duplicates
to be summed up, so that element (i, j) counts transitions from i to j
(and no duplicates exist after compression).

Is this more clear?

On Sun, Feb 7, 2016 at 9:14 PM, Patrick Alken <alken@colorado.edu> wrote:
> Hi Alexis,
>
>>> I'm not sure what you mean. I've added a new function gsl_spmatrix_ptr
>>> to the git, which as far as I can tell does exactly what your
>>> sum_duplicate flag does. It searches the matrix for an (i,j) element,
>>> and if found returns a pointer. If not found a null pointer is returned.
>>> This makes it easy for the user to modify A(i,j) after it has been added
>>> to the matrix. Are you thinking of something else? Can you point me to
>>> the Eigen routine?
>>>
>> What I meant is to have the equivalent of gsl_spmatrix_compress,
>> with the difference that gsl_spmatrix_ptr is used instead of gsl_spmatrix_set,
>> so has to build the compressed matrix from triplets, summing the
>> duplicates, instead of replacing them.
>> This is what is done here :
>> The http://eigen.tuxfamily.org/dox/classEigen_1_1SparseMatrix.html#a5bcf3187e372ff7cea1e8f61152ae49b
>>
>> Best,
>> Alexis
>
> I'm not sure why a user would ever need to do this. The whole point of
> the binary tree structure in the triplet storage is to efficiently find
> duplicate entries, so that if a user tries to call gsl_spmatrix_set on
> an element which is already been previously set, it can find that
> element with a binary search (rather than linearly searching the arrays)
> and change the value of that element.
>
> Therefore, the way the triplet storage is designed, there is will never
> be a duplicate element in the triplet arrays. All of the (i[n],j[n])
> will be unique for each n <= nz.
>
> Am I missing something?
>
> Patrick



-- 
Alexis Tantet