[Follow-ups were not on the ML. Copy/paste below.] Hello.
Le mer. 21 août 2019 à 02:59, Tom Prodehl <t...@prodehl.com> a écrit : > > I can accommodate passing all the data at once instead of permitting > piecemeal > > addition. The algorithm requires that the x values be in increasing > order so > > either the data is provided in sorted order via SortedMap or SortedSet > or I have > > to sort it to be sure. > I've just noted that "HarmonicCurveFitter" and "GaussianCurveFitter" both define a (different) "sortObservations" private method, as it is also requirement for their guessing procedure (see below). [I'd think that this duplication is unwarranted, and that the sort method should be moved to the "WeightedObservations" utility class.] > > On 8/20/2019 1:55 PM, Gilles Sadowski wrote: > > Hi. > > > > Le mar. 20 août 2019 à 17:38, Tom Prodehl <t...@prodehl.com> a écrit : > >> The proposed contribution does not fit within the current design of > >> theo.a.c.m.fittingpackage. > >> The radically different approach to estimate the parameters makes it > >> unsuitable to simply drop it there. > >> > >> Design decisions > >> <http://www.apache.org/foundation/governance/pmcs.html#communication>must > >> happen on the"dev" ML <http://commons.apache.org/mail-lists.html>; so a > >> discussion/must/be started there. > >> > >> So what makes this fitting technique not suitable for the package? > > Because, the boiler-plate code in that package (i.e. "AbstractCurveFitter") > > assumes that the fit is performed through an iterative process.[1] > > > > Also, a.o. differences, your class assumes that data can be added > > incrementally, while the "CurveFitter" assume that all data is passed at > > once. > > We try to provide a consistent APIs. [It's quite possible that the current > > one is not right, and if so we should improve or change it.] > > > >> And > >> what suggestions might you have? > > We could create a new package ("a.o.c.math4.fitting.noninterative"?). > > Works for me and perhaps if the other equation types have a similar > approach as > > you suggest below, it would be logical to gather them there. > > > > > And we should come up with a design that can accomodate both > > approaches, if possible. Or that make it clear what the differences > > are (both for future development and from a usage POV). > Knowing the details of those differences is beyond my expertise > > > >> The reference is written in French, but the math parts are universal. > >> Original source: Regressions et Equations integrales, Jean Jacquelin > >> https://www.scribd.com/doc/14674814/Regressions-et-equations-integrales > > The paper indicates that the technique can be applied to other functions. > > So it seems that the design should distinguish between the reusable parts > > (aka "boiler-plate") and the specifics of each function. > > As I do not know French, I cannot easily discern where the boilerplate > lies. > > Perhaps you could assist my understanding, if you understand the paper > as it seems you do Unfortunately, I don't have the time to do more than the quick look which I gave it. However I wonder whether this approach was in fact used in "HarmonicCurveFitter": Please have a look at the "ParameterGuesser" inner class. If so, then IMHO the best way forward is to implement the exponential fitting functionality along the same lines, i.e. define a new class (in the "o.a.c.m.fitting" package): public class ExponentialCurveFitter extends AbstractCurveFitter { // "Exponential" function (to be defined in package "o.a.c.m.analysis.function"). private static final Exponential.Parametric FUNCTION = new Exponential.Parametric(); public static class ParameterGuesser { // Here comes the code deduced from J. Jacquelin's paper. } // Factory methods. } This will entail that the iterative fit can always be performed, at the user's choice, with no additional burden. The "Exponential" referred to above is the function to be fitted, i.e. in your code: y = a2 + b2 * exp(c2*x) I'd suggest more explicit names for the parameters, e.g. (?) y = offset + scale * exp(rate * x) The function object must be defined in package "o.a.c.m.analysis.function" (following the same design as the other classes in the "function" package): public class Exponential implements UnivariateFunction { // ... Methods "value" (instance and "static"). public static class Parametric implements ParametricUnivariateFunction { // ... @Override public double[] gradient(double x, double ... param) { // ... } } HTH, Gilles > > > >> I know of no English translation. > > Is this approach implemented in other libraries? > Not that I know, and I did a search that was extensive to me. > > > > Regards, > > Gilles > > > > [1] > > http://commons.apache.org/proper/commons-math/apidocs/org/apache/commons/math4/fitting/AbstractCurveFitter.html > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
