From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5178 invoked by alias); 8 Feb 2016 00:59:47 -0000 Mailing-List: contact gsl-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gsl-discuss-owner@sourceware.org Received: (qmail 5156 invoked by uid 89); 8 Feb 2016 00:59:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*Ad:U*gsl-discuss, Best, sum X-HELO: mail-ig0-f169.google.com Received: from mail-ig0-f169.google.com (HELO mail-ig0-f169.google.com) (209.85.213.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 08 Feb 2016 00:59:44 +0000 Received: by mail-ig0-f169.google.com with SMTP id mw1so47785902igb.1 for ; Sun, 07 Feb 2016 16:59:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4iW5IWefESEQ52OiVfZZpo565Nz6aAk//IMxV0IDBT8=; b=YGvyQZQkoWuqpInoMbLb30XVYGARegstUilLUy/pSPu51oxxdNFDRa4YrCW1znQYi5 lBmClm+qOzrkQZt21t4BCJ90UZVZ2QjihyW3nY0FUJVTQ4x2WFmD2TRbajlU84ig7fes kW2uxc7KQANcEQq5VD0KIOyEk5WDRcPA+pRXjIS8TrLJZa4vfZ0q1DHra/MUpgWiXmBM KVOQ+uAqFxeYT18Jfczrj8r5R5WOkGX8drVN8rXP1CTmdZ3Cwmxgqr/S+u11XK0qVANj 0fRx5QgU0eVM/JvXz6IIqN0yz+jssjbYPJngf23LfPvVtgL0S5xJJqeolVcxrFIkMnPZ giKA== X-Gm-Message-State: AG10YOQ7YtXS1WWJxY7V+NS0nN28ZZ5hbMz/Xop1dYLoNe190XmGT96j+PA81KguVu0fLhJnJjBWsoAn5aofng== MIME-Version: 1.0 X-Received: by 10.50.134.129 with SMTP id pk1mr21562390igb.11.1454893182229; Sun, 07 Feb 2016 16:59:42 -0800 (PST) Received: by 10.79.118.141 with HTTP; Sun, 7 Feb 2016 16:59:42 -0800 (PST) In-Reply-To: <56B7B85C.10508@colorado.edu> References: <569E6C33.1090505@colorado.edu> <569EA1A9.2080101@colorado.edu> <56B689B1.5090005@colorado.edu> <56B77E13.1000306@colorado.edu> <56B7A59D.5040707@colorado.edu> <56B7B85C.10508@colorado.edu> Date: Mon, 08 Feb 2016 00:59:00 -0000 Message-ID: Subject: Re: Sparse matrix extension From: Alexis Tantet To: Patrick Alken Cc: "gsl-discuss@sourceware.org" Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2016-q1/txt/msg00012.txt.bz2 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 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 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