> > [...] > > > > 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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
