commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: svn commit: r1042596 - in /commons/proper/math/trunk/src/main/java/org/apache/commons/math: analysis/solvers/ distribution/
Date Mon, 06 Dec 2010 23:29:29 GMT
On Mon, Dec 6, 2010 at 5:35 PM, Luc Maisonobe <Luc.Maisonobe@free.fr> wrote:

> Hi Gilles,
>
> Le 06/12/2010 23:27, Gilles Sadowski a écrit :
> > Hi.
> >
> >>> Log:
> >>> MATH-452
> >>> Made all static variables (accuracies) "private".
> >>
> >>
> >> We have already started a discussion on a similar point some months ago.
> >> Last message is here: <http://markmail.org/message/m4l7v4pdfp5yn3as>,
> >> but we did not really conclude.
> >>
> >> To summarize my point from a few months ago, one use case for these
> >> public values is that a use program can do something like this to first
> >> initialize a Graphical User Interface, then let the user change the
> >> values he wants, and later retrieve the actual values (which may be
> >> unchanged) to build the solver.
> >>
> >> // initialize GUI
> >>
> solverGui.setRelAccuracy(BaseAbstractUnivariateRealSolver.DEFAULT_RELATIVE_ACCURACY);
> >>
> solverGui.setAbsAccuracy(BaseAbstractUnivariateRealSolver.DEFAULT_ABSOLUTE_ACCURACY);
> >>
> >> // fire the GUI
> >> ...
> >>
> >> // in the action callback from the GUI OK button, create the solver
> >> double rel = solverGui.getRelAccuracy();
> >> double abs = solverGui.getAbsAccuracy();
> >> BrentSolver mySolver = new BrentSolver(rel, abs);
> >>
> >>
> >> Another simpler use case is simply to have the default value available
> >> in the Javadoc without being forced to get commons-math sources.
> >>
> >> So I still consider this kind of public constats are usefule. Despite
> >> the fact within commons-math they are used only in some constructors,
> >> the fact they are public allow them to be also used in user code.
> >
> > I think that we can satisfy this use-case without exposing the variables:
> >
> > ---CUT---
> >> BrentSolver mySolver = new BrentSolver();
> >>
> >> // initialize GUI
> >> solverGui.setRelAccuracy(mySolver.getRelativeAccuracy());
> >> solverGui.setAbsAccuracy(mySolver.getAbsoluteAccuracy());
> >>
> >> // fire the GUI
> >> ...
> >>
> >> // in the action callback from the GUI OK button, create the solver
> >> double rel = solverGui.getRelAccuracy();
> >> double abs = solverGui.getAbsAccuracy();
> >>
> >> mySolver = new BrentSolver(rel, abs);
> > ---CUT---
>
> Creating two solvers to use only one and simply hiding constants seems
> awkward to me. Just letting the constants visible is simpler.
>
> I think what Sebb pointed out in this issue was not that the constants
> were public, but that these constants were duplicated. I agree with him
> here. However solving the issue by removing the duplication and having
> constants defined in the top level interface is more straightforward.
>

+1.  One more thing that Gilles was careful to maintain, but gives more
reason to keep the constants public is that they are part of the
documentation - e.g.

-     * Construct a solver with default accuracy.
+     * Construct a solver with default accuracy (1e-6).

Keeping the constants public eliminates the need to repeat this.

Phil

>
> best regards,
> Luc
>
> >
> >
> > Regards,
> > Gilles
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message