Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Wed, 18 Sep 2013 10:59:55 +0000 (UTC)
From: "Thomas Neidhart (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.12601503.1344184730850.153978.1379501995797@arcas>
In-Reply-To: <JIRA.12601503.1344184730850@arcas>
References: <JIRA.12601503.1344184730850@arcas>
Subject: [jira] [Commented] (MATH-842) Investigate why Bland's rule in
 Simplex Solver still creates cycles
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/MATH-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13770653#comment-13770653 ] 

Thomas Neidhart commented on MATH-842:
--------------------------------------

No, not really.

The options object would be just a container for lots of int/double/boolean/enum fields/flags that would be provided to the solver, either before or during the optimize call. These options are also very specific to the solver, so there is no need to generalize them in one way or another. Implementing OptimizationData would allow to specify it during the call to optimize, but I would also be fine to make it part of the solver interface, e.g. SimplexSolver.withSolverOptions(SimplexSolverOptions).

What I did not like about the OptimizationData is that we attempted to create a common interface for things that are different, and that it was not clear which optimizer uses or requires which input. It would make sense to unify things if you could replace one instance with another, but this is clearly not the case: you can not use e.g. a BrentOptimizer to solve a linear problem, yet the API allows it (at least theoretically).

We also did not gain anything wrt thread-safety, as each optimizer stores all the passed OptimizationData in its instance (not that I think thread-safety for algorithm classes should be the main design goal), and I did not see the benefit of providing all the required inputs as part of the call to a generic optimize method.

What we should have done: exclude the optimize method from the BaseOptimizer class and provide specific ones for classes of optimizers that support the Liskov substitution principle, e.g. the LinearOptimizer defines a optimize method with a signature that *all* LinearOptimizer instances support. Then you could create e.g. a DualSimplex or PrimalSimplex optimizer both implementing the same interface, and you can exchange one implementation with another.
                
> Investigate why Bland's rule in Simplex Solver still creates cycles
> -------------------------------------------------------------------
>
>                 Key: MATH-842
>                 URL: https://issues.apache.org/jira/browse/MATH-842
>             Project: Commons Math
>          Issue Type: Improvement
>    Affects Versions: 3.1
>            Reporter: Thomas Neidhart
>            Assignee: Thomas Neidhart
>         Attachments: MATH-842.patch
>
>
> As a consequence of MATH-828, Bland's rule has been introduced to prevent cycling. Now there are cases where cycles can still occur (see testMath828Cycle in SimplexSolverTest). These cases have for now been solved with a simple heuristic:
>  * after maxIterations / 2 -> ignore Bland's rule
> This issue has been created to further investigate the problem and come up with a cleaner solution.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira