Re: Sparse matrix extension

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

Ok, my mistake, now I see where I got confused.
I had in mind to add all the elements first to the triplets and only
while converting to compressed sum up the duplicates.
While, indeed, if there's a way you can sum up the duplicates directly
while adding them to the triplet matrix (thanks to _ptr), this is more
handy and efficient.

Thanks for the clarification,
Alexis

On Sun, Feb 7, 2016 at 10:34 PM, Patrick Alken <alken@colorado.edu> wrote:
> By design, gsl_spmatrix_set won't allow you to do this.
>
> If you add element (i, j, x) and then later to try add element (i, j,
> y), gsl_spmatrix_set will detect that there exists an element in the (i,
> j) spot and it will simply change x to y - the value of x will be
> overwritten by y. This is the same behavior as gsl_matrix_set.
>
> So no duplicates are allowed by design. If you have such an application
> where you want to keep track of duplicates, you could do the following:
>
> double *ptr = gsl_spmatrix_ptr(m, i, j);
> if (ptr)
>   *ptr += x; /* sum duplicate values */
> else
>    gsl_spmatrix_set(m, i, j, x);   /* initalize to x */
>
> On 02/07/2016 01:31 PM, Alexis Tantet wrote:
>> 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