commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles (JIRA)" <>
Subject [jira] [Updated] (MATH-1014) Remove optimizer from constructor of "CurveFitter" sublasses
Date Mon, 05 Aug 2013 02:03:48 GMT


Gilles updated MATH-1014:


I've attached replacements for
* CurveFitter (new class is "AbstractCurveFitter")
* GaussianFitter (new class is "GaussianCurveFitter")

Main changes are:
# the choice of optimizer is a developer's decision (instead of a user's one),
# the base class still contains utilities ("TheoreticalValuesFunction") but they must be called
by the subclass if it needs it: i.e. most inputs to the optimizer are passed at the subclass
level (since in principle they depend on the type of optimizer used),
# "GaussianCurveFitter" uses the new implementation of LM (with "fluent" API),
# a fluent API is also used for capabilities of the specific fitter; e.g. "GaussianCurveFitter"
advertizes a "WithStartPoint" capability (to pass first guess values for the parameters).[1]

[1] This indicates that interfaces such as "WithStartPoint" have a broader scope (the generics
parameter need not be an "optimizer", as currently documented), and could thus be placed in
a higher level package.
> Remove optimizer from constructor of "CurveFitter" sublasses
> ------------------------------------------------------------
>                 Key: MATH-1014
>                 URL:
>             Project: Commons Math
>          Issue Type: Improvement
>    Affects Versions: 3.2
>            Reporter: Gilles
>            Assignee: Gilles
>            Priority: Minor
>              Labels: api-change
>             Fix For: 4.0, 3.3
>         Attachments:
> In package "o.a.c.m.fitting", the constructor of the concrete subclasses of "CurveFitter"
(currently: "PolynomialFitter", "GaussianFitter", "HarmonicFitter") takes a "MultivariateVectorOptimizer"
> However, assuming that there is _one_ best choice for the optimizer (given the parametric
function), this argument should not be left to the user's choice (i.e. it should be hidden
within the class, and the best optimizer be transparently selected).
> Thus, I would propose to deprecate the non-default constructor.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message