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

Reply via email to