Commons Math
  1. Commons Math
  2. MATH-1014

Remove optimizer from constructor of "CurveFitter" subclasses

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 3.2
    • Fix Version/s: 3.3
    • Labels:

      Description

      In package "o.a.c.m.fitting", the constructor of the concrete subclasses of "CurveFitter" (currently: "PolynomialFitter", "GaussianFitter", "HarmonicFitter") takes a "MultivariateVectorOptimizer" argument.

      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.

      1. MATH-1014.zip
        7 kB
        Gilles
      2. MATH-1014.zip
        8 kB
        Gilles

        Issue Links

          Activity

          Hide
          Gilles added a comment -

          I've attached replacements for

          • CurveFitter (new class is "AbstractCurveFitter")
          • GaussianFitter (new class is "GaussianCurveFitter")

          Main changes are:

          1. the choice of optimizer is a developer's decision (instead of a user's one),
          2. 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),
          3. "GaussianCurveFitter" uses the new implementation of LM (with "fluent" API),
          4. 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.

          Show
          Gilles added a comment - 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.
          Hide
          Gilles added a comment -

          Uploaded new version that also includes the changes proposed in that message.
          This goes a long way towards the fitter classes being immutable.

          Show
          Gilles added a comment - Uploaded new version that also includes the changes proposed in that message . This goes a long way towards the fitter classes being immutable.
          Hide
          Gilles added a comment -

          New container class "WeightedObservationPoints" introduced in revision 1516059.

          Show
          Gilles added a comment - New container class "WeightedObservationPoints" introduced in revision 1516059.
          Hide
          Gilles added a comment -

          New class "o.a.c.m.fitting.AbstractCurveFitter" added in revision 1516854 (to serve as a new base class for fitter implementations, replacing the "CurveFitter" class).

          Show
          Gilles added a comment - New class "o.a.c.m.fitting.AbstractCurveFitter" added in revision 1516854 (to serve as a new base class for fitter implementations, replacing the "CurveFitter" class).
          Hide
          Gilles added a comment -

          New class "o.a.c.m.fitting.GaussianCurveFitter" added in revision 1516896 (replacing "o.a.c.m.fitting.GaussianFitter").

          Show
          Gilles added a comment - New class "o.a.c.m.fitting.GaussianCurveFitter" added in revision 1516896 (replacing "o.a.c.m.fitting.GaussianFitter").
          Hide
          Gilles added a comment -

          TODO: Create similar classes to replace "HarmonicFitter" and "PolynomialFitter".

          Show
          Gilles added a comment - TODO: Create similar classes to replace "HarmonicFitter" and "PolynomialFitter".
          Hide
          Gilles added a comment -

          "HarmonicCurveFitter" created in revision 1520807.

          Show
          Gilles added a comment - "HarmonicCurveFitter" created in revision 1520807.
          Hide
          Gilles added a comment -

          "PolynomialCurveFitter" created in revision 1543906.

          Show
          Gilles added a comment - "PolynomialCurveFitter" created in revision 1543906.
          Hide
          Gilles added a comment -

          Some time ago, it is has been noted on the ML that the Levenberg-Marquardt algorithm was not the most efficient for fitting a polynomial.
          Another optimizer can be plugged into the code when available.

          Deprecated classes must be removed when preparing the next major release.

          Show
          Gilles added a comment - Some time ago, it is has been noted on the ML that the Levenberg-Marquardt algorithm was not the most efficient for fitting a polynomial. Another optimizer can be plugged into the code when available. Deprecated classes must be removed when preparing the next major release.
          Hide
          Gilles added a comment -

          Those classes are deprecated as of 3.3 (replaced by subclasses of "AbstractCurveFitter").
          They will be entirely removed in 4.0.

          Show
          Gilles added a comment - Those classes are deprecated as of 3.3 (replaced by subclasses of "AbstractCurveFitter"). They will be entirely removed in 4.0.
          Hide
          Luc Maisonobe added a comment -

          Closing all resolved issue now available in released 3.3 version.

          Show
          Luc Maisonobe added a comment - Closing all resolved issue now available in released 3.3 version.

            People

            • Assignee:
              Gilles
              Reporter:
              Gilles
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development