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

Reply via email to