Re: gsl Development Query

["E. Robert Tisdale" <edwin at netwood dot net>]

Gerard Jungman wrote:

> Brian Gough wrote:
> 
> > What you've outlined is something much bigger
> > than GSL (i.e. it's not GSL).
> 
> No. What I have described is an efficient way
> to obtain the required functionality in GSL.
> These are implementation details.
> If you feel there are some fundamental flaws
> in existing implementations,
> then you are free to reimplement. I don't see
> the flaws in existing (and Free!) implementations
> such as BLAS and FFTW.
> 
> And how can it possibly matter to the end user?
> All they want is something that works,
> and that works in the right way,
> without making undesirable assumptions
> about usage patterns or data representation.
> These important issues are _interface_ issues.
> Their only relation to the elemental entity
> turning the crank under the hood
> is to specify certain constraints
> that any such implementation must satisfy.
> If you find a solution to those constraints,
> then you have satisfied the design criteria.
> If the solution happens to already exist,
> then so much the better; you can go home early.
> 
> > GSL is just a collection of routines for numerical computing,
> > written in C with modern coding conventions.
> 
> Yes, that's what it says in The Big Book of GSL.
> Now, rather than quoting the precious scripture to me,
> why don't you apply your native intelligence
> and think about whether or not it makes any sense.
> 
> The so-called "design" of this library
> was never anything more than some vague wish list.
> The original idea that you could provide
> "loosely coupled" libraries for the different tasks
> was wrong.  This was made clear
> when Brian and I got down to worrying about
> the various multi-dimensional functionalities
> which depend explicitly on data structures
> for vectors and matrices and linear algebra support.
> The linear algebra bottleneck should be obvious to everyone
> who has done any numerical computing;
> if you don't solve this problem first, you are screwed.
> 
> When you take the time to look at the requirements
> for implementing higher level algorithms,
> you realize that the design must be layered
> and you must solve the fundamental problems first.
> These include things like control of and access
> to the floating point capabilities of the machine,
> data representation issues, and basic linear algebra.
> 
> When you (Brian) and I faced these problems squarely,
> about two years ago, we found it necessary
> to redesign and reimplement large sections of the project,
> fixing things related to the issues above,
> as well as doing the right thing at higher levels,
> such as introducing a consistent framework for iteration.
> 
> When you say "well, we're just a collection of tools",
> you are just echoing the original design goals,
> which have been demonstrated, by your own work,
> to be confused.
> 
> > Maybe a "universal interface/library"
> > of the type you suggest is worthwhile --
> > but it would be a different project from GSL.
> 
> I'm not talking about a "universal interface/library",
> whatever that is.  I'm talking about the right way
> to provide an underlying implementation
> for some of the required functionality.
> 
> > If you need wrappers for fortran codes,
> > they are available in other places
> > (e.g. Octave's library, NumPy, ...).
> 
> Yes, they are. So?
> 
> Nobody "needs" wrappers for fortran codes.
> They need tools that do certain tasks.
> Wrapping fortran just happens to be
> a convenient way to get certain functionality.
> That's why people do it,
> not because they like to know that
> a little fortran monkey is turning the crank
> in their greasy little simulated worlds.
> Who cares what turns the crank, as long as it turns?
> 
> > The idea of GSL is that wrapping
> > is never completely satisfactory
> > and so it's better to rewrite things.
> 
> Let me paraphrase this for the general reader:
> The idea of GSL is to write half-assed implementations
> of some ill-defined collection of numerical foo,
> sometimes of functionality that already exists,
> with no real thought going into the overall design,
> and to pat each other on the back
> for having done everything the hard way
> and put it under the GPL.
> Well, GPL'ed foo is still foo;
> that's one thing I know for sure
> after having watched the free software world work
> for the last ten years.
> 
> You have this idea that GSL is just some thing
> that we are tinkering with in the backyard,
> not really "important" enough to do the right way;
> after all, nobody's going to the moon riding on a GSL rocket.
> This is insulting to everyone involved, including yourself.
> 
> > However much you wrap unreadable fortran,
> > it's still unreadable fortran.
> 
> Huh? What does this mean? This is a non sequitur.

Evidently, you and Brian
each have a very different vision for the GSL.
Brian's aspirations are rather modest.
He just wants to implement a numerical library
that he can distribute free of charge to people
who can't afford the $50 or whatever it costs
to purchase a copy of Numerical Recipes in C.
For him, the GSL is just another software project.
His plan is to simply allow the GSL to evolve.
Apparently, he believes that GSL users
are amateur application programmers who want to write
short lived disposable application programs
like most of the programmers at LANL for example.
He doesn't worry about supporting poor API design decisions
because he doesn't expect any applications using the GSL
to survive much beyond the next version of the GSL.

Personally, I would prefer an API for the GSL that
professional as well as amateur programmers could use.
Professional programmers are more interested in writing
long lived reusable application programs.
I don't think that many professional programmers
would dare risk using the GSL because, apparently,
it isn't reasonable to expect Brian or anyone else
to support it for very long.

Anyway, I don't think Brian is prepared to design an API.
If you want someone to design an API for the GSL,
you will probably need to do it yourself which means that
you will need to contribute to the design documentation
and submit specific proposals -- in writing.
The API should not dictate how it is to be implemented.
Implementation details should be left up to
the library developer --
Brian if he agrees to implement the API.