Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement a clean API to decide whether or not to extract solver values #163

Open
Midnighter opened this issue May 29, 2018 · 6 comments
Open

Comments

@Midnighter
Copy link
Member

Please see the source of this issue in opencobra/cobrapy#714. Basically, we would like a clean way to decide whether or not it is okay to extract primals (and duals).

@KristianJensen
Copy link
Contributor

KristianJensen commented May 30, 2018

I think I see what it is that you want. However it seems like it will always depend a lot on the specific application whether it is "okay" to get the values from a particular type of non-optimal solution?
I think the only thing that can really be done in optlang is to make sure that the status classifications are consistent and meaningful, so that an application, e.g. cobrapy can decide how to handle each of the optlang statuses. This is a bit tricky though as the different solvers define different statuses that do not always translate well. Suggestions are welcome.

@KristianJensen
Copy link
Contributor

Or is it just this has_primals = [NUMERIC, FEASIBLE, INFEASIBLE, SUBOPTIMAL, ITERATION_LIMIT] particularly that you would like to have in optlang?

@Midnighter
Copy link
Member Author

It would be a start. Just wanted to start a discussion on whether that's the way it should be handled or if we look at alternative ways that solve the problem in a bit more general fashion. For example, a while back we introduced the property is_integer to decide whether dual values are available or not.

@KristianJensen
Copy link
Contributor

Just to be sure: Is it a question of whether it's technically possible to get the values from the solver, or is it a question of whether it's meaningful to do so?

If it's the former, I agree that it would make sense to have e.g. a has_values property on the Model, to check whether there are values available for a given status with a given solver.

@Midnighter
Copy link
Member Author

@cdiener can probably explain this better than I do. The question is about the latter. We don't always expect it to be a valid solution at that point but looking at the values can still be informative as to why the solver failed.

@cdiener
Copy link
Member

cdiener commented May 30, 2018

@KristianJensen It would be the first (whether it's technically possible). This is to be able to inspect a non-optimal solution. For instance SUBOPTIMAL or even NUMERIC solutions might still be interesting to inspect since they are often very close to the optimal solution. We would still raise a warning if such a solution is requested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants