Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Date: Thu, 17 Jan 2013 20:24:26 +0100
From: Gilles Sadowski <gilles@harfang.homelinux.org>
To: dev@commons.apache.org
Subject: Re: [math] OptimizationData and LinearConstraintSet
Message-ID: <20130117192426.GS5526@dusk.harfang.homelinux.org>
Mail-Followup-To: dev@commons.apache.org
References: 
 <CAJSjvwsdA6qOrrQ5G_dAapPpuJeRhbQ7XCeXhFipyZqQNNU2ew@mail.gmail.com>
 <20130117145229.GQ5526@dusk.harfang.homelinux.org>
 <CAJSjvwuF30mCgUtTdya-9upqxG9C177cV97PS7JKykJoyrPSow@mail.gmail.com>
 <20130117152141.GR5526@dusk.harfang.homelinux.org>
 <50F845C6.9070804@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <50F845C6.9070804@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-DCC-scarlet.be-Metrics: eir 20001; Body=1 Fuz1=1 Fuz2=1
X-Virus-Scanned: clamav-milter 0.97.1-exp at eir
X-Virus-Status: Clean
X-Virus-Checked: Checked by ClamAV on apache.org

> > [...]
> > 
> > If we do not have the resources to dig further into the real problem, we can
> > circumscribe it by indicating which interval of epsilon values are
> > considered trustworthy (and declining all resposibility if user try pushing
> > the implementation too far).
> 
> Well, I do disagree.
> I do not want to have a situation where users get different results with
> each run. I want to have deterministic behavior for deterministic
> algorithms.

Do you suggest that the JVM algorithm is not deterministic? ;-)

> Yes, there are numerical stability issues, which in this case can be
> treated by relaxing the convergence criteria as the user did.

Then, I propose that lower bound of the convergence criterion be set as a
precondition and the algorithm will be deterministic in a more obvious way.

> Otoh, we should have thorough testing where a permutation of the linear
> constraints could be a useful addition to detect more such issues. For
> such a flexible tool like the SimplexSolver, there will always be
> problems where the solution is difficult to find, and will require some
> tuning. Even octave (using the very good and mature glpk library) did
> not find the optimal solution in this case.

This even further convinces me that we should not change an implementation
detail: such details simply must not have visible side-effects.
It has a visible effect here because the precondition is not satisfied.


Regards,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org