public inbox for gsl-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Joseph Wakeling <joseph.wakeling@webdrake.net>
To: gsl-discuss@sourceware.org
Subject: Re: Flat (uniform) random distribution and some development/contribution queries
Date: Tue, 11 May 2010 15:35:00 -0000	[thread overview]
Message-ID: <4BE97939.1080307@webdrake.net> (raw)
In-Reply-To: <43fx1yilox.wl%bjg@gnu.org>

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

      reply	other threads:[~2010-05-11 15:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-10 11:15 Joseph Wakeling
2010-05-10 14:23 ` Joseph Wakeling
2010-05-11 14:42   ` Brian Gough
2010-05-11 14:42 ` Brian Gough
2010-05-11 15:35   ` Joseph Wakeling [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BE97939.1080307@webdrake.net \
    --to=joseph.wakeling@webdrake.net \
    --cc=gsl-discuss@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).