Re: gsl Development Query

[Brian Gough <bjg at network-theory dot co dot uk>]

 > My main concern for GSL is some API inconsistency. For instance shouldn't
 > 
 > gsl_fft_complex_radix2_forward(gsl_complex_packed_array *data,size_t
 > stride, size_t n)
 > 
 > have some sort of vector input?

This is one of several things I need to document, I will try to do
that. There are some variations in the API are part of the design and
there are some inconsistencies which are genuine, due to different
developers following different paths and which we are still working
on.  I will explain this particular point here since it is actually
part of the design,

For purely "1d" functions we use the C-style arguments (double *,
stride, size) so that it is simpler to use the functions in a normal C
program, without needing to invoke all the gsl_vector machinery.

The philosophy here is to minimise the learning curve. If someone only
needs to use one function, like an fft, they can do so without having
to learn about gsl_vector.  

This leads to the question of why we don't do the same for matrices.
In that case the argument list gets too long and confusing, with
(size1, size2, tda) for each matrix and potential ambiguities over row
vs column ordering. In this case, it makes sense to use gsl_vector and
gsl_matrix, which take care of this for the user.

So really the library has two levels -- a lower level based on C types
for 1d operations, and a higher level based on gsl_matrix and
gsl_vector for general linear algebra.

Of course, it would be possible to define a vector version of the
lower level functions too. So far we have not done that because it was
not essential -- it could be done but it is easy enough to get by
using the C arguments, by typing v->data, v->stride, v->size instead.
A gsl_vector version of low-level functions would mainly be a
convenience.