Re: GSL 2.0 roadmap

["Robert G. Brown" <rgb@phy.duke.edu>]

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