From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13492 invoked by alias); 27 Aug 2009 12:51:47 -0000 Received: (qmail 13483 invoked by uid 22791); 27 Aug 2009 12:51:46 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail.phy.duke.edu (HELO mail.phy.duke.edu) (152.3.182.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 27 Aug 2009 12:51:39 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.phy.duke.edu (Postfix) with ESMTP id 272F3BEE7A; Thu, 27 Aug 2009 08:49:42 -0400 (EDT) Received: from mail.phy.duke.edu ([127.0.0.1]) by localhost (mail.phy.duke.edu [127.0.0.1]) (amavisd-new, port 10026) with LMTP id czexJ8UAVWHo; Thu, 27 Aug 2009 08:49:42 -0400 (EDT) Received: from lilith.rgb.private.net (client212-5.dsl.intrex.net [209.42.212.5]) by mail.phy.duke.edu (Postfix) with ESMTP id 67A97BED7C; Thu, 27 Aug 2009 08:49:41 -0400 (EDT) Date: Thu, 27 Aug 2009 12:51:00 -0000 From: "Robert G. Brown" To: Tuomo Keskitalo cc: Brian Gough , GSL Discuss Mailing List Subject: Re: GSL 2.0 roadmap In-Reply-To: <4A967114.8080600@iki.fi> Message-ID: References: <48E25CA9.6080306@iki.fi> <490DE4BD.7070907@iki.fi> <497B00F6.2080400@iki.fi> <498727E5.6080407@iki.fi> <49AA9DB5.6030908@iki.fi> <49FB01D1.30000@iki.fi> <4A7ADFDC.9080408@iki.fi> <4A967114.8080600@iki.fi> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: 2009-q3/txt/msg00020.txt.bz2 On Thu, 27 Aug 2009, Tuomo Keskitalo wrote: > Hello, > > thanks for the list. I was wondering that since there will be a new major > version, this might be a good chance to modify some of the APIs / frameworks. > Is this OK? For example, when I was implementing msadams and msbdf for > ode-initval, I had to make some modifications to the algorithms in order to > fit them into GSL ode-initval framework. It is clear that the stepper, > control and evolve objects would sometimes benefit from mutual communication. > Should ode-initval framework be changed so that this kind of communication is > possible in future? > > How long would it be before 2.0 is out, approximately? More or less than a > year? It might be good idea to keep the 2.0 branch "unstable" for some time, > before APIs are frozen (if changes to frameworks are OK). On the same note, a rather long time ago I developed a set of GSL-ish "tensor" structures to enable the GSL to handle things beyond matrices (which involved of course redefining slightly 1st and 2nd rank tensors, or at least paralleling the matrix and the vector). Tensors are, obviously useful to all sorts of people doing computations in physics; not only spatial tensors in e.g. relativistic theory computations but also angular moment tensors that may not be efficiently rectangular. Also, the GSL has lacked multidimensional quadrature; I ported one algorithm from the C++ Hint package long ago to a GSLish form, but it would be good at some point to consider adding an "extensible" set of quadrature over d>1 spaces, where the "simple" solution of nested integration is often horrendously inefficient and even inaccurate, especially if the space involved is curved e.g. the surface of a sphere. Finally, there are a number of possible additions to the roster of RNGs out there, including relatively slow ones of cryptographic quality that can serve purposes that even the best of the fast generators arguably cannot, plus code that I wrote for dieharder that will automagically add e.g. /dev/random and /dev/urandom if they exist to the list. I haven't worked with the first two for a while now, but I've still got the code (of course) and would be happy to de-mothball it if there is any interest in reconsidering the vector/matrix/tensor interface so it is more extensible. I think I implemented all the way out to 10th rank tensors -- possibly overkill even for relativity, but I myself use at least sixth rank in some of my code, and I'm aware of people who need eighth rank. rgb > > On 08/21/2009 11:41 PM, Brian Gough wrote: > >> * Changes for Release 2.0 >> Break binary compatibility, but keep source compatibility. > > Does "source compatibility" mean that user interfaces / APIs should not be > changed? > >> ** Convert to BZR? (check GPG signing and integrity guarantees) > > Do you mean http://bazaar-vcs.org/Bzr ? > Would this mean to abandon git? > > -- > Tuomo.Keskitalo@iki.fi > http://iki.fi/tuomo.keskitalo > Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@phy.duke.edu