commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Neidhart <>
Subject Re: [math] OptimizationData and LinearConstraintSet
Date Thu, 17 Jan 2013 14:59:20 GMT
On Thu, Jan 17, 2013 at 3:52 PM, Gilles Sadowski <> wrote:

> On Thu, Jan 17, 2013 at 02:28:56PM +0100, Thomas Neidhart wrote:
> > Hi,
> >
> > by investigating a recent issue (MATH-930), I discovered that the newly
> > introduced LinearConstraintSet stores the constraints internally in a
> > HashSet.
> > This leads to undeterministic behavior as the iteration order of
> > constraints is not fixed (especially between different JRE versions).
> >
> > TBH, I never reviewed this change and I am a bit surprised to see it.
> Imho
> > there is no need to have a Set here, and would prefer to change this to a
> > list implementation.
> -1
> Unless the order of iteration is a requirement of the mathematical
> description of the algorithm.
> If so:
>  * This requirement should appear prominently in the Javadoc.[1]
>  * Please discard the rest of this mail.
> If not, then the order is only an implementation detail (IOW, with infinite
> precision, the solution would not change with different iteration orders),
> I would be cautious to rely on a specific implementation of the container
> used to store input data.
> Maybe that the behaviour described in MATH-930 indicates an inherent
> weakness of the algorithm (or too stringent requirements); if so, the
> better
> solution is probably not to rely on whether side-effects are visible or
> not.
> Also, I note that in the (deprecated) package
> "o.a.c.m.optimization.linear",
> the constraints are passed to "optimize" as a
>   Collection<LinearConstraint>
> IIUC, the same behaviour could thus be produced by a user who'd call
> optimize several times, passing the same set of constraints but stored in a
> different order in the Collection.

Hi Gilles,

yes I understand your concerns, and the problem is two-fold:

 * make the algorithm behave deterministic in all environments
   (I do not want to spend each time 1 day debugging why it works in one
case or another)

 * fix the obvious numerical stability problem with certain ordering of

Although before the parameter was passed as a Collection, most people
actually used a List or something similar.
At least you had control over it, now it is just a HashSet, inside a CM
class which you can not control.

So I would really prefer to at least change it to a LinkedHashSet with
deterministic iteration order, and investigate further the other problem.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message