Re: GSL-0.9 -> Standard interface to functions/pakages

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

Nicolai Hanssing writes:
 > First of, it should be suffcient for the solvers, and minimizers with one
 > interface to usersupplied functions and derivatives:
 > .....
 > gsl_(???)_function_f: 
 > int (* f) (const gsl_vector * X, void * PARAMS, gsl_vector* F)
 > gsl_(???)_function_df:
 > int (* df) (const gsl_vector * X, void * PARAMS, gsl_matrix * J)
 > gsl_(???)_function_fdf:
 > int (* fdf) (const gsl_vector * X, void * PARAMS, gsl_vector * F,gsl_matrix * J)
 > 
 > Currently each optimizing-pakage has it own similar definition, when the
 > interface above clearly should be sufficient.
 >
 > Next up, using the above definition GSL should be able to provide the
 > users with a simplified interface to both solvers, minimizers and
 > maximizers. I.e. use of the interface should only be 3-4 steps:
 >
 > My point is that little enhancements, and the ability to try functions
 > implemented in gsl, without the need of a big program to setup *all*
 > options, and allocations would greatly improve upon
 > development-time, allthough the pakage might give a performancehit. It can
 > be seen as a higherlevel interface to lowerlevel functions. If users want
 > more direct control, they can offcourse use the lower-level pakages
 > directly.

The library is oriented towards interfacing to scripting languages, so
the routines are low-level and broken down into fundamental
components.  The structs for gsl_multifit_.., gsl_multiroots_.., etc
should be regarded as part of the interface, as a way to pass in a
collection of arguments, rather than a mathematical object. The
functions correspond to a library, rather than an 'environment'. So
from this point of view its natural that the multiroots, multifit and
multimin modules use different structs.  If you'd like to make a
separate higher-level interface for C/C++ programming feel free to do
that.