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?
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.
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
