I was suggesting (though not clearly :) keeping the MultivariateJacobianFunction interface as is and adding a new interface for any post processing of the evaluated point. Something like:
interface StepFinalizer { RealVector apply(RealVector point); } Then we would add another getter/setter to LeastSquaresProblem for an instance StepFinalizer. As I think more about it, I think this interface could also be used to satisfy another feature request we've had in the past: recording the trajectory that the optimizer takes. In this case the step finalizer would have a side effect of adding the point to a list for later retrieval. What do you think? Best Regards, Evan On 09/08/2014 11:13 AM, Gilles wrote: > Hello. > > > > On Mon, 8 Sep 2014 08:56:36 -0400, Evan Ward wrote: > >> Gilles, >> >> >> >> I like this approach. My only thought is that a separate interface >> for >> >> the validate method would be nicer for our Java 8 users. Then the >> >> implementation could be a lambda: (p) -> p.unitVector() >> > > > Do you mean define an interface like > > > > interface ValidatingMultivariateJacobianFunction > > extends MultivariateJacobianFunction { > > > > /** > > * @param point Point provided by the optimizer. > > * @return the point that will actually be evaluated. > > */ > > RealVector validate(RealVector point); > > } > > > > and then use "instanceof" to check whether validation should occur > > or not? > > > > Gilles > > > >> Best Regards, >> >> Evan >> >> >> >> On 09/07/2014 08:11 PM, Gilles wrote: >> >>> On Thu, 4 Sep 2014 12:52:24 -0400, Evan Ward wrote: >>> >>>> Hi Olexiy, >>>> >>>> >>>> >>>> In my field we often encounter a similar problem when estimating >>>> >>>> attitude since a quaternion is only a valid rotation when it is >>>> >>>> normalized. We often escape this issue by estimating a "small" >>>> >>>> adjustment to an apriori guess. (For the details see [1].) For >>>> this >>>> >>>> technique to work the cost function must be smooth and the apriori >>>> guess >>>> >>>> must be "close enough" to the true value. Both of these assumptions >>>> are >>>> >>>> also required to apply a non-linear least squares optimizer. >>>> Perhaps you >>>> >>>> can apply a similar technique to your problem. (It seems that your >>>> 'A' >>>> >>>> parameter is orientation in 3D space.) >>>> >>>> >>>> >>>> If there is a need for an extra steps, I would prefer to make those >>>> >>>> explicit rather than depending on side effects of cost function >>>> >>>> evaluation. >>>> >>> >>> >>> IIUC, the feature could be made explicit by adding a method to the >>> >>> "MultivariateJacobianFunction" interface to allow the user to change >>> >>> the point about to be evaluated: >>> >>> >>> >>> interface MultivariateJacobianFunction { >>> >>> Pair<RealVector, RealMatrix> value(RealVector point); >>> >>> >>> >>> /** @param point Point provided by the optimizer. */ >>> >>> /** @return the point that will actually be evaluated. */ >>> >>> RealVector validate(RealVector point); >>> >>> } >>> >>> >>> >>> Thus, in "LeastSquaresFactory": >>> >>> >>> >>> private static class LocalLeastSquaresProblem >>> >>> extends AbstractOptimizationProblem<Evaluation> >>> >>> implements LeastSquaresProblem { >>> >>> >>> >>> // ... >>> >>> >>> >>> private final MultivariateJacobianFunction model; >>> >>> >>> >>> // ... >>> >>> >>> >>> public Evaluation evaluate(final RealVector point) { >>> >>> final RealVector p = model.validate(point).copy(); // <--- >>> Change >>> >>> here (at line 403). >>> >>> >>> >>> if (lazyEvaluation) { >>> >>> return new LazyUnweightedEvaluation(model, >>> >>> target, >>> >>> p); >>> >>> } else { >>> >>> final Pair<RealVector, RealMatrix> value = model.value(p); >>> >>> return new UnweightedEvaluation(value.getFirst(), >>> >>> value.getSecond(), >>> >>> target, >>> >>> p); >>> >>> } >>> >>> } >>> >>> >>> >>> // ... >>> >>> } >>> >>> >>> >>> What do you think? >>> >>> >>> >>> Best, >>> >>> Gilles >>> >>> >>> >>>> >>>> >>>> Best Regards, >>>> >>>> Evan >>>> >>>> >>>> >>>> [1] Crassidis, John L., and John L. Junkins. /Optimal Estimation of >>>> >>>> Dynamic Systems/. Boca Raton, FL: CRC, 2012. >>>> >>>> >>>> >>>> On 09/04/2014 05:37 AM, Olexiy Movchan wrote: >>>> >>>>> Hello, >>>>> >>>>> >>>>> >>>>> I created the math issue >>>>> >>>>> https://issues.apache.org/jira/browse/MATH-1144. >>>>> >>>>> >>>>> >>>>> In version 2.0, LevenbergMarquardtOptimizer passed point to >>>>> >>>>> evaluator by reference. So our software could modify it on every >>>>> >>>>> step of algorithm. >>>>> >>>>> In version 3.3, point is copied and then passed to evaluator, so >>>>> it >>>>> >>>>> can't be updated by evaluator. >>>>> >>>>> >>>>> >>>>> We use LevenbergMarquardtOptimizer for 3d surface fitting >>>>> >>>>> (cylinders, cones, tori) by sampled points. And surface parameters >>>>> >>>>> should be renormalized on every step of algorithm. Please see this >>>>> >>>>> article: >>>>> >>>>> >>>>> http://nvlpubs.nist.gov/nistpubs/jres/103/6/j36sha.pdf >>>>> >>>>> >>>>> >>>>> Also please read the description of MATH-1144 jira issue. >>>>> >>>>> >>>>> >>>>> Can you modify optimizer or evaluator interface to allow in/out >>>>> >>>>> parameters there? >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Olexiy Movchan >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> >>> 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 > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org