[
https://issues.apache.org/jira/browse/MATH-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13770681#comment-13770681
]
Gilles commented on MATH-842:
-----------------------------
bq. No, not really.
bq. [...] e.g. SimplexSolver.withSolverOptions(SimplexSolverOptions).
If {{withSolverOptions}} is defined in an interface, then
{{SimplexSolverOptions}} will most probably be an implementation of an
interface (say, {{Options}}). {{Options}} is thus equivalent to
{{OptimizationData}}: a marker interface (since you indicated that a bunch of
options are implementation-specific).
bq. 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.
"Not clear" could refer to a documentation issue, to better highlight
_required_ "options" (which is why "OptimizationData" was not named
"OptionData").
The purpose was to allow the passing of the same list of options to different
optimizers, and each would pick the data it needs. I, at least, had a use for
that; but I can agree that it is not a common pattern, especially in strongly
typed languages.
bq. you can not use e.g. a BrentOptimizer to solve a linear problem, yet the
API allows it [...]
This was a trade-off in order to inherit code which all optimizers need (e.g.
the counters). Sometimes multiple inheritance is useful.
If we completely depart from the original design (based on a single hierarchy),
many improvements become possible (as with Evan's proposal, and what Luc
proposes for ODE, IIUC).
bq. What we should have done [...]
No, we could not have done that; because nobody proposed it.
> 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
