Bug #45782

[Bill Maier <shufflesky@hotmail.com>]

The actual implementation of this feature is rather straightforward. The
function that numerically computes the Jacobian already has a parameter for
epsilon, so it's just a question of getting that information from the user to
the function call.

The main question I have is how to give the user a way to specify this
epsilon while maintaining backward compatibility. Right now the interface
for multiroot solvers is well-defined: alloc, set, iterate, and free. The
most obvious place to introduce an additional parameter would be in the
"set" call, gsl_multiroot_fsolver_set(), but currently there's no facility
there for another parameter. We could add another argument to the call which
would contain the epsilon value. Just tacking it on would lose backward
compatibility, but we could create an additional "set" call, something like
gsl_multiroot_fsolver_params_set(). This call would have an additional
argument, something like "fsolver_params" which would be a structure with
additional parameters for the solver including the epsilon value. We would
then have two "set" calls for fsolvers. Using a new structure allows for
future parameters to be added if needed.

Another option which leaves the current user interface intact would be
to add the epsilon parameter to the gsl_multiroot_fsolver structure. In the
function gsl_multiroot_fsolver_alloc() function the epsilon value would be
set to the current default of GSL_SQRT_DBL_EPSILON to maintain backward
compatibility. If the user wanted it to be something different, he would set
the epsilon value manually with a line of code like
    solver->epsilon = 1.0e-4
at a point after the solver allocation but before the call to
gsl_multiroot_fsolver_set(). This option has the advantage of maintaining the
current user interface, but establishing a manual bypass to it doesn't seem
like a good design choice.

I am interested in hearing from other GSL developers and users which option
they think is the most appropriate for this library. Personally I think the
first option, adding a new "set" call with an additional argument, is the
cleanest way to go, though it does expand the user interface.

-Bill Maier