Use Evaluation instead of PointVectorValuePair in the ConvergenceChecker. This
gives the checkers access to more information, such as the rms and covariances.
The change also simplified the optimizer implementations since they no longer
have to keep track of the current function value.
A method was added to LeastSquaresFactory to convert between the two types of
checkers and a method added to LeastSquaresBuilder so that it can accept either
type. I would have prefered to do this through method overloading, but
overloading doesn't play well with generics.
git-svn-id: https://svn.apache.org/repos/asf/commons/proper/math/trunk@1569353 13f79535-47bb-0310-9956-ffa450edef68
Changed the boolean useLu prarameter to an enum. This is benificial because:
1. user code is easier to read: new GNO(Decomposition.QR) instead of new GNO(false)
2. Allows other algorithms to be added in the future
3. developer code is easier to read. One less if statement in optimize()
git-svn-id: https://svn.apache.org/repos/asf/commons/proper/math/trunk@1569352 13f79535-47bb-0310-9956-ffa450edef68
The main loop in GN could only be ended by convergence or exception. I made that
explicit with while(true) and removed an unreachable MathInternalError.
git-svn-id: https://svn.apache.org/repos/asf/commons/proper/math/trunk@1569350 13f79535-47bb-0310-9956-ffa450edef68
A new interface MultivariateJacobianFunction lets the function value and
Jacobian be evaluated at the same time. This saves the user from having to cache
the result between calls to get the value and the jacobian.
A factory method was added to create LeastSquaresProblems from the new interface.
git-svn-id: https://svn.apache.org/repos/asf/commons/proper/math/trunk@1569346 13f79535-47bb-0310-9956-ffa450edef68
The weights are no longer implicit in LeastSquaresProblem.Evaluation. They are
already included in the computed residuals and Jacobian.
GN and LM multiplied the residuals by the weights immediately, so that was easy
to remove.
Created an AbstractEvaluation class which handles the derived quantitied (cost,
rms, covariance,...) and two implementations. UnweightedEvaluation uses the
straight forward formulas. DenseWeightedEvaluation delegates to an Evaluation
and multiples the residuals and Jacobian by the square root of the weight matrix
before returning them. Allowed me to remove the reference to the full weight
matrix.
git-svn-id: https://svn.apache.org/repos/asf/commons/proper/math/trunk@1569344 13f79535-47bb-0310-9956-ffa450edef68
The GN and LM optimizers now use an immutable fields for their configuration
parameters and a fluent api. LM still has some mutable fields it uses a scratch
space.
This commit is a backport of Evan Ward github commit
https://github.com/wardev/commons-math/commit/157cdde
into the current development version.
Conflicts:
src/main/java/org/apache/commons/math3/fitting/leastsquares/GaussNewtonOptimizer.java
src/main/java/org/apache/commons/math3/fitting/leastsquares/LevenbergMarquardtOptimizer.java
git-svn-id: https://svn.apache.org/repos/asf/commons/proper/math/trunk@1569343 13f79535-47bb-0310-9956-ffa450edef68
The least squares package now has two main interfaces LeastSquaresOptimizer and
LeastSquaresProblem, where the optimizer can be applied to the problem.
In this commit all of the test cases pass with one change (annotated) to
LevenbergMarquardt.testControlParameters(). The tests for Gauss Newton were
expanded to cover using the QR decomposition, which revealed a QR default
tolerance discrepancy.
A factory and a mutable builder were create for LeastSquaresProblem.
This commit is a backport of Evan Ward github commit
7e9a15efb5
into the current development version.
Conflicts:
src/main/java/org/apache/commons/math3/fitting/leastsquares/AbstractLeastSquaresOptimizer.java
src/main/java/org/apache/commons/math3/fitting/leastsquares/GaussNewtonOptimizer.java
src/main/java/org/apache/commons/math3/optim/AbstractOptimizer.java
src/test/java/org/apache/commons/math3/fitting/leastsquares/AbstractLeastSquaresOptimizerAbstractTest.java
src/test/java/org/apache/commons/math3/fitting/leastsquares/GaussNewtonOptimizerTest.java
src/test/java/org/apache/commons/math3/fitting/leastsquares/LevenbergMarquardtOptimizerTest.java
git-svn-id: https://svn.apache.org/repos/asf/commons/proper/math/trunk@1569342 13f79535-47bb-0310-9956-ffa450edef68
The previous version was based on Welzl algorithm, but it appeared this
algorithm really need some properties that hold in Euclidean spaces and
not on the sphere.
The current version is not perfect in the sense that some times the
enclosing spherical cap returned is not the smallest possible. It is
documented in the Javadoc.
git-svn-id: https://svn.apache.org/repos/asf/commons/proper/math/trunk@1567599 13f79535-47bb-0310-9956-ffa450edef68
In simple cases (small polygon, one piece only, no holes), the enclosing
cap will be the smallest one, but this is not guaranteed in the general
case.
The enclosing cap can be used to speed up inside/outside points when the
region is small with respect to the sphere as with only one check of an
angular separation, most points of the sphere can be safely identified
as outside. The more time-consuming checks involving the full boundary
are therefore done only for a small portion of the sphere.
git-svn-id: https://svn.apache.org/repos/asf/commons/proper/math/trunk@1566358 13f79535-47bb-0310-9956-ffa450edef68
In almost coplanar / almost colinear cases, sphere generation could
diverge in such a way the support points did not belong to the sphere
anymore! This new implementation uses exact arithmetic for the
computation. It is much slower, but since very few balls should be
generated during the Welzl algorithm execution, this is probably
acceptable.
JIRA: MATH-1096
git-svn-id: https://svn.apache.org/repos/asf/commons/proper/math/trunk@1563712 13f79535-47bb-0310-9956-ffa450edef68
Luc Maisonobe
Thomas Neidhart