Tue 08 Dec 2015 07:55:28 PM UTC, comment #3:
Dear Bill,
many thanks for working on this feature!
From a user perspective, I think both approaches would be fine, because both are easy to use.
However, from the software design point of view, I agree with your opinion that the first option would be cleaner. It would also allow to add further options later. For a user it would be important to well document the new "gsl_multiroot_fsolver_params_set()" function (and maybe add a user example).
Best,
Alex

Mon 23 Nov 2015 08:10:31 PM UTC, comment #1:
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 welldefined: 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.0e4;"
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

Mon 17 Aug 2015 05:38:43 PM UTC, original submission:
Dear GSL hackers,
for my research project I'm using the GSL multiroot solvers (w/o derivative). However, I stumbled upon a numerical problem:
The function that I'm passing to the multiroot solvers cannot be evaluated very precisely. I.e. there is a numerical imprecision in the function evaluation of the order 1e5.
When I pass this function to the multiroot solvers (w/o providing a function for the derivative), one of the first things the solver does is to calculate the Jacobian. For the calculation of the Jacobian matrix different derivatives of the function have to be calculated numerically. For the calculation of these derivatives a hardcoded epsilon of GSL_SQRT_DBL_EPSILON = 1.4901161193847656e08 is used. This value is too small for my application, because it is smaller than the numerical imprecision of the function evaluation. In my case 1e4 would be optimal.
For this reason I'd like to request the following feature: Please make the epsilon, which is used in the calculation of the Jacobian, configurable.
Best regards,
Alexander Voigt
