commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [Math] About the API of the optimizers
Date Fri, 05 Oct 2012 14:56:05 GMT

> > [...]
> >>
> >> What I clearly don't like in our setting is the complexity of the
> >> hierarchy with the generics. I have the same reluctance with the solvers
> >> hierarchy, and was directly hit by both when I needed to had a new
> >> function type for differentials (see
> >> <>
> >> and
> >> <>).
> >> So I would be very happy if we could simplify our hierarchy here and
> >> mainly remove the top level generics (like BaseOptimizer<PAIR> and
> >> BaseMultivariateOptimizer<FUNC extends MultivariateFunction> extends
> >> BaseOptimizer<PointValuePair> and simply have a set of parallel
> >> non-generics interfaces with fixed signatures, one for each type we
> >> need.

To be clear, you are referring to the "user" interfaces which I enumerated

> >> These top level interfaces don't add much value and completely
> >> prevent to implement several of them in one class, due to type erasuer
> >> (something we did not notice when we designed this). Their javadoc even
> >> states "This interface is mainly intended to enforce the internal
> >> coherence of Commons-Math. Users of the API are advised to base their
> >> code on the following interfaces:".
> > 
> > I am responsible for the current hierarchy design but it was based on an
> > earlier one, not much simpler, but with much more duplicated code.
> > At refactoring the identified goal was to merge all the codes that could be.
> > 
> > The point is that different algorithm have generated different based on
> > several points:
> >  * Univariate vs multivariate function
> >  * Scalar vs sector function
> >  * "optimize" return type: "PointValuePair" vs "PoinVectorValuePair"
> > 
> > The generics were used to "summarize" all the existing flavours (and push
> > common features one level up). [Boilerplate code in "Abstract..." classes.]
> > 
> >> A coworker of mine asked me today which interface he should use in the
> >> signature of a method he was writing and which should take an optimizer
> >> as an argument. He was puzzled by our hierarchy and did not understand
> >> which level he should use in his declaration. Even knowing the
> >> internals, the history, the various implementations and their
> >> differences, it took me almost an hour to answer his question. So our
> >> hierarchy really needs to be streamlined.
> > 
> > The user interfaces didn't change I think, and do not refer to generics.
> Yes, this is exactly my point. These interfaces are not for users, they
> are for [math] developers.

The interfaces with a generic parameter ("T" or "FUNC") are not for users;
those without generic parameters (but which extends a generic with a
specific type in place of "T" ot "FUNC") are for users (those enumerated
below). I that what you mean?

> However, they do confuse users who see them
> and even reading the javadoc don't understand their purpose. They also
> prevent an implementation to support two interfaces at a time and hence
> to be smoothly upgraded as we improve our basic users interfaces.

I have mixed feelings. Indeed it is a pity that generics do not really
create new types; it is type erasure that got in your way, not the generics.

But I agree that in the end, it's not necessary to keep interfaces just for
internal use: We should be able to avoid redundancy and keep code
duplication just by respecting a policy. Of course, the refactoring was
done _because_ the last statement was not true. ;-)

> > They are
> >  * DifferentiableMultivariateVectorOptimizer
> >  * DifferentiableMultivariateOptimizer
> >  * DifferentiableMultivariateMultiStartOptimizer
> >  * DifferentiableMultivariateVectorMultiStartOptimizer
> >  * MultivariateMultiStartOptimizer
> >  * MultivariateOptimizer
> >  * UnivariateOptimizer 
> > 
> > [Anything whose names start with "Base..." or "Abstract..." is neither for
> > users nor for application developers but for developers of concrete algorithms
> > for CM.]
> > 
> > 
> > What do you propose? Wat is streamlining a library?
> I propose to remove the generics from pure interfaces (this would have
> to wait for 4.0, of course), and hence reduce the number of layers at
> least by one, and if possible by more than one.

All simplifications are welcome :-).
I think that my proposal (cf. original subject of this thread) is also
about simplication of the API (for easier usage):

1. Construct an optimizer.
2. Call the "optimize" method.
[No intermediate calls to specific methods that are not in the general API.]


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

View raw message