This is the mail archive of the gsl-discuss@sources.redhat.com mailing list for the GSL project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: gsl Development Query


Brian Gough wrote:
> 
> What you've outlined is something much bigger that 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 has to be layered, and you have
to 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.


-- 
G. Jungman

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]