commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [math] refactoring least squares
Date Thu, 20 Feb 2014 13:34:19 GMT

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 

Is the "computation" vs "access to a precomputed value" mandated by
the interface?

> 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 
same structure could allow for not duplicating computations necessary 
compute both.

> 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 
every implementation should reuse. The abstract class could indeed be
relocated in "util" to stress its "internal" status.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message