commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Evan Ward <>
Subject Re: [Math] Fluent API, inheritance and immutability
Date Tue, 13 Aug 2013 21:47:18 GMT

On 08/13/2013 08:17 AM, Gilles wrote:
>> (I.e. GN would
>> not need 5 superclasses and fields for storing upper and lower bounds.)
> Be careful: "GaussNewtonOptimizer" does _not_ support bounds!

That is my point! Because of it's complex inheritance every instance
includes fields for storing bounds even though the algorithm has no use
for them. (Declared in BaseMultivariateOptimizer) I was looking at the
released (3.2) version. Looks like it has since been fixed. :)

>> With the API re-design you have the opportunity to design for thread
>> safety, which can be hard to add on to an existing API.
> True in general, but in this case we didn't make a thorough analysis
> of advantages and drawbacks of creating a new instance for each
> application of a "withXxx" method.
> I previously hinted that such a behaviour might not be desirable,
> independently of the issue of thread-safety.
>> Thanks for the whole discussion; It has given me some new ideas. :)
> You are most welcome to experiment with the current revision of the
> code in "o.a.c.m.fitting.leastsquares", in order to pinpoint problems
> for your use-cases.
> You could also provide the concrete changes (patch) needed to move the
> "data" to another object, as you suggested.
> If it's better design and leads to simpler code, there shouldn't be
> any problem in applying it for the next release.

I separated the algorithm from the problem definition for the
GaussNewton optimizer. See If we decide to go
this route LM would follow the same pattern. It still needs some
polishing and a few smaller API decisions.

A summary of the changes:
  - The two superclasses of GN were turned in to
AbstractOptimizationProblem and LeastSquaresProblemImpl. I tried to keep
most of the code the same so that a diff would be meaningful.
  - Interfaces were extracted from LeastSquaresProblemImpl and
AbstractOptimizationProblem. I kept the upper level of the hierarchy as
an implementation aid.
  - GaussNewton implements LeastSquaresOptimizer and does not have a
super class. Evaluation and iteration counts are now locals.
  - There is now one method to evaluate the model/problem, see
LeastSquaresProblem.evaluate(double[]). This returns a container with
the value and Jacobian.

  - GaussNewton is now trivially easy to make immutable and fluent and
thread-safe. This will allow the same algorithm to be applied to
different problems.
  - If the model function and convergence checker are thread safe, then
so is the LeastSquaresProblem (if you don't mutate it). This would allow
different algorithms to be applied to the same problem. These are the
two big bullet points that I think make it worthwhile. :)
  - Allows algorithms to be applied to problems they weren't designed
for by using "views". I.e. view a least squares problem as a direct
problem by creating an implementation of DirectProblem that delegates to
a LeastSquaresProblem. A similar delegation would work to view a
DirectOptimzier as a LeastSquaresOptimizer.
  - Same code for the most part, just reorganized.

Further decisions:
  - It would be nice to have a model interface that could be evaluated
with one method call. E.g. Pair<double[], double[][]> value(double[]).
  - Leave getWeights() out of the LeastSquaresProblem API? This would
help encapsulation, but would require further modification of the GN
  - Should the LeastSquaresProblem interface include mutators? I think
it makes sense to only include the methods that the optimization
algorithm needs to "read". That would keep the API smaller and not tie
the users to a particular implementation.
  - method and class names.

I'm sure there are a few more issues. :) Thanks for considering the
separate API.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message