On 11/16/2013 09:13 PM, Gilles wrote: > 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.
once collections 4 is released, I will have more time to look at these issues and review his patch. But I have to say that I do not agree with the semantics right now. The behavior is really weird and something I am not used to from other APIs. Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
