public inbox for
 help / color / mirror / Atom feed
* Bug #45782
@ 2015-11-23 20:07 Bill Maier
  0 siblings, 0 replies; only message in thread
From: Bill Maier @ 2015-11-23 20:07 UTC (permalink / raw)
  To: gsl-discuss

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

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2015-11-23 20:07 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-23 20:07 Bug #45782 Bill Maier

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).