On Fri, Aug 17, 2012 at 09:40:49AM +0100, sebb wrote: > On 17 August 2012 07:40, Luc Maisonobe <luc.maison...@free.fr> wrote: > > Le 16/08/2012 23:48, sebb a écrit : > >> On 16 August 2012 21:58, Gilles Sadowski <gil...@harfang.homelinux.org> > >> wrote: > >>> Hello. > >>> > >>> In classes "HarmonicFitter" and "GaussianFitter" (in package > >>> "o.a.c.m.optimization.fitting"), there is an inner class > >>> "ParameterGuesser". > >>> All the necessary input for the guessing procedure is passed to the > >>> constructor; I thus propose that the guessing is performed at object > >>> construction rather than at the call to the "guess()" method. This will > >>> allow to declare all the fields "final". Moreover, all that can go wrong > >>> will be located in the constructor, turning the "guess" method into a mere > >>> accessor. > > > > +1 to Gilles suggestion. > > > >> > >> On the face of it, it sounds like the class does not even need to be > >> instantiated. > >> Could the guess method be turned into a static utility method to which > >> the parameters are passed? > >> Why bother creating an instance only to return the guess later? > > > > It could be. There are a bunch of methods involved and they exchange > > data which is now stored in a few class fields (observation arrays and > > the three estimated parameters), so these data should be added as > > parameters to the static functions. > > > > I'm not sure whether it is cleaner to have a small instance created for > > a short time to perform some difficult preprocessing or to have a bunch > > of static methods. > > Instances need to be disposed of by GC whereas parameters > automatically disappear when a called procedure returns.
As a short-lived object, I guess that performance will not be improved greatly (especially w.r.t. the time taken for the fitting itself). > A class with no fields is guaranteed immutable. The class will be immutable. > > But for large numbers of parameters, class data is perhaps cleaner. Being "public", the inner class cannot disappear now; so I'll do the first cleanup, and we'll see later if further changes are in order. Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
