From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84361 invoked by alias); 7 Feb 2016 20:31:49 -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 84339 invoked by uid 89); 7 Feb 2016 20:31:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2261, H*Ad:U*gsl-discuss, Best, H*r:sk:gsl-dis X-HELO: mail-io0-f179.google.com Received: from mail-io0-f179.google.com (HELO mail-io0-f179.google.com) (209.85.223.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sun, 07 Feb 2016 20:31:47 +0000 Received: by mail-io0-f179.google.com with SMTP id g73so177607465ioe.3 for ; Sun, 07 Feb 2016 12:31:47 -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=7moN6yOBxWsBCKdEi9Q7JC6C8h8aJsVNEqsfCoLDpms=; b=d/0TBDVZltV8Jxpc6vu5zq5l4xOBuQtFTNlrjmALgTXCt93grOYgJ8zCxZrpguLEfL kbn398k/Xqq6Y1zlReTX9yRKwEH0IsgXfJ8i2MZZ/u+1Fy43gu2sJq/Kk5n9StpYDT4G MoaCNKf2GmuadCH2x5SeQyGeaetCPr4HDJMa45bZDTToc+BFi7XU0o69uyusPw6otPX4 1qld2bWZYEo2/0WCncsyVUJGSGFZhSazl+m/xQhacmrb2BojkqyPhYVjRhBtFsnaY42c F3Udzdm7um/LMkX96Zb3Bx1I0ycXaKhyhHrjtBpfj/xh+u3V1IF7hIhIqCt7sAvLFy4+ L25g== X-Gm-Message-State: AG10YOReFmKjTQ3i5AqJWwOw6j+bwuNFlCcluUhfxsFU213I+OeIXPLxuFuk7cQ7lm5QEi+KgVyuEnBoxKMRvA== MIME-Version: 1.0 X-Received: by 10.107.186.195 with SMTP id k186mr25302060iof.90.1454877105571; Sun, 07 Feb 2016 12:31:45 -0800 (PST) Received: by 10.79.118.141 with HTTP; Sun, 7 Feb 2016 12:31:45 -0800 (PST) In-Reply-To: <56B7A59D.5040707@colorado.edu> References: <569E6C33.1090505@colorado.edu> <569EA1A9.2080101@colorado.edu> <56B689B1.5090005@colorado.edu> <56B77E13.1000306@colorado.edu> <56B7A59D.5040707@colorado.edu> Date: Sun, 07 Feb 2016 20:31: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/msg00010.txt.bz2 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