On Fri, Aug 17, 2012 at 01:24:50PM +0100, sebb wrote: > On 17 August 2012 12:15, Gilles Sadowski <gil...@harfang.homelinux.org> wrote: > > On Fri, Aug 17, 2012 at 11:46:22AM +0100, sebb wrote: > >> On 17 August 2012 11:24, Gilles Sadowski <gil...@harfang.homelinux.org> > >> wrote: > >> > 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. > >> > >> Is the class directly usable by 3rd parties? > > > > Yes. > > > >> Would it make sense for a 3rd party to use it directly? > > > > Maybe. They could compare the guessed values with the optimized ones. > > Admittingly, this is not very useful... if everything works fine. > > > >> > >> If not, then although it would break strict binary compat., it would > >> be possible to consider changing it. > >> If it's not directly used by 3rd party code, I don't think changes can > >> break their code. > > > > I don't understand: the class is public. Someone can have instantiated it in > > his code... > > Not if the following is true: > > >> If it's not directly used by 3rd party code
But you cannot know whether it is used or not. Or am I missing something? > > >> > >> Ideally any such helper classes should be private or package protected > >> ab initio. > > > > I agree. > > However in this case, the boundary between helper and utility (that could be > > useful on its own) is not clear-cut. > > > > > > Gilles > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
