On Thu 20 Feb 2014 08:34:19 AM EST, Gilles wrote: > > Hi. > > On Thu, 20 Feb 2014 10:05:58 +0100, luc wrote: >> >> Hi all, >> >> I am looking more precisely at the least squares package and have a >> few adjustments to propose. >> >> The Evaluation interface declares a computeValue and a >> computeJacobian method among others. >> However, it seems the implementations are really simply built with >> the precomputed values and >> just return them. The other compute methods (for covariances for >> instance) do really compute >> something based on the stored Jacobian or value. >> Wouldn't it be more clear to use "getValue" and "getJacobian" for >> these two methods and keep >> "compute" for the other ones? > > > I recall that we did not want "...Impl" classes. Is another > implementation > foreseen? > > Is the "computation" vs "access to a precomputed value" mandated by > the interface?
+1 for renaming to getXxx(). We could even rename all the methods to start with get. Since we have an interface (and when the computations happen is purposefully not specified), I see the pre-compute and cache vs compute on method call tradeoff as an implementation detail. If all the methods start with 'get' then the whole interface will be consistent with itself and with Java conventions. As for the Impl classes, theses are package private implementations of interfaces, so the users won't see the name. For the LeastSquareProblem interface I could see a lazy evaluation implementation, or perhaps an implementation that applies data editing by zeroing out certain residuals. > >> >> Another point is binding value and Jacobian together in a single >> object. I personally think it >> is a good thing, but if I remember well, some users explicitly asked >> for separating them to save >> some computation. I'm not sure about this, though, so I would like to >> have some advices. > > > Unless I'm mixing up things, it was the opposite: having them within the > same structure could allow for not duplicating computations necessary to > compute both. I agree with Gilles, for all my use cases it is easiest to compute both value and Jacobian at the same time. Regards, Evan > >> >> >> Last point is OptimizationProblem. Should this interface been in >> fitting or in a more general >> package, and in this case which one (optim, util)? > > > What's the usefulness of an interface? It's only boiler-plate code which > every implementation should reuse. The abstract class could indeed be > relocated in "util" to stress its "internal" status. > > Regards, > 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
