On Sat, 16 Nov 2013 18:17:15 +0100, Thomas Neidhart wrote:
Hi,
while working on MATH-970, I realized that the current way of
handling
all the OptimizationData arguments for the optimize and
parseOptimizationData methods is somehow flawed.
All the OptimizationData is parsed and stored in the instance itself,
but not reset between subsequent calls of optimize.
This behavior is described in BaseOptimizer#optimize:
When the method is called multiple times, instance data is
overwritten
only when actually present in the list of arguments: when not
specified,
data set in a previous call is retained (and thus is optional in
subsequent calls).
This can lead to subtle errors/mistakes that are difficult to track
down, especially when optional flags have a default value, like for
the
SimplexSolver:
SimplexSolver solver = new SimplexSolver();
solution = solver.optimize(DEFAULT_MAX_ITER, f, new
LinearConstraintSet(constraints),
GoalType.MINIMIZE,
new NonNegativeConstraint(true));
solution = solver.optimize(DEFAULT_MAX_ITER, f, new
LinearConstraintSet(constraints),
GoalType.MINIMIZE);
The default value for nonNegative = false, thus one could think that
the
second call would enforce no nonNegative solution, but in fact will
return the same result as the first call.
This is intended, and the documentation says as much, as you indicated.
This can be easily solved by making sure that the
parseOptimizationData
is resetting any optional arguments, but I wanted to get some
feedback
first and whether this behavior is really desired.
-1 on changing the semantics of the current code.
However, the change of design proposed by Evan Ward in
https://issues.apache.org/jira/browse/MATH-1026
looked promising.
Unfortunately, I didn't have the time to thoroughly review his latest
patch. The main things would be to ensure the new design has no obvious
drawbacks, and that it provides the promised flexibility (fluent API,
immutability, weights handling).
If agreed on, the same design should obviously be applied to the other
optimizers.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org