From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5069 invoked by alias); 11 May 2010 15:35:33 -0000 Received: (qmail 5061 invoked by uid 22791); 11 May 2010 15:35:32 -0000 X-SWARE-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,BAYES_05,TW_BZ X-Spam-Check-By: sourceware.org Received: from up.nbi.dk (HELO mail2.nbi.dk) (130.225.212.6) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 11 May 2010 15:35:27 +0000 Received: from [192.168.9.216] (unknown [193.206.22.97]) by mail2.nbi.dk (Postfix) with ESMTP id 17EA03C922 for ; Tue, 11 May 2010 17:35:22 +0200 (CEST) Message-ID: <4BE97939.1080307@webdrake.net> Date: Tue, 11 May 2010 15:35:00 -0000 From: Joseph Wakeling User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: gsl-discuss@sourceware.org Subject: Re: Flat (uniform) random distribution and some development/contribution queries References: <4BE7EAAD.20603@webdrake.net> <43fx1yilox.wl%bjg@gnu.org> In-Reply-To: <43fx1yilox.wl%bjg@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2010-q2/txt/msg00016.txt.bz2 On 05/11/2010 03:59 PM, Brian Gough wrote: > I think this is what gsl_ran_choose does. The implementation isn't as > efficient as those described but it gives the same result. Ahh, yes. The interest I have is in doing something a bit different -- sampling which doesn't require the data to be presented in a predefined set as gsl_ran_choose does, so it's space- as well as speed-efficient. The particular motivation in my case was having to make an efficient selection of a subset of links from a fully-connected bipartite graph. That means choosing from N*M potential links, where N and M could both be very large. > Since I'm limited in the time I can spend on GSL these days the main > thing is for any code I deal with to be well tested and debugged in > actual use before submission. If it is in specific areas like linear > algebra maybe other people like Patrick Alken can help. If there are > multiple changes needed after something is submitted it becomes > problematic, particularly if they necessitate changes to the API. Completely understand. What I will aim for is to develop this code independently but with a design that will make it easy to incorporate into GSL proper if/when it has received sufficient review. If that never happens ... well, I'll have had fun working on it, and it will be useful for my own work in any case. > Currently > bzr branch http://bzr.savannah.gnu.org/r/gsl/trunk ... yea, but I don't want to branch the whole of GSL :-) What I'll do is, the moment I have something working-ish with even the stupidest demo, I'll put it up in a new Savannah project and make a little announcement here and on the help-gsl list just so people know what is happening. (Incidentally, part of the demo could be an alternative version of gsl_ran_choose, for purposes of comparison...). >From the GSL point of view I guess the main useful feedback would be on design factors to make it fit well with GSL proper. On the testing side I'll try and build some bridges with the sampling algorithms community -- I think there are some packages contributed to R, so maybe the people responsible would give some review or contribution. I guess the existing tests for gsl_ran_choose would also apply. Best wishes, -- Joe