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

Zero coefficients cause panic "invalid problem: Warning" #5

Closed
evolutics opened this issue Aug 20, 2022 · 3 comments
Closed

Zero coefficients cause panic "invalid problem: Warning" #5

evolutics opened this issue Aug 20, 2022 · 3 comments

Comments

@evolutics
Copy link

Thanks for maintaining these LP libraries.

I've noticed the following when using good_lp with Highs, hence reporting it here.

Input

Example program:

use highs::{RowProblem, Sense};

fn main() {
    let mut problem = RowProblem::new();
    // Minimize x + y subject to x ≥ 0, y ≥ 0.
    let x = problem.add_column(1., 0..);
    let y = problem.add_column(1., 0..);
    let c = 0.; // Try changing this to something nonzero.
    problem.add_row(..1, &[(x, 1.), (y, c)]); // 1 ≥ x + c y.
    let solution = problem.optimise(Sense::Minimise).solve().get_solution();
    println!("{:?}", solution.columns());
}

Actual output

When run with highs 1.2.1, it panics at the optimise call:

thread 'main' panicked at 'invalid problem: Warning', …/highs-1.2.1/src/lib.rs:200:34

Expected output

It should just print the unique solution to the problem (x = y = 0) without panicking.

highs 0.6.1 works as expected.

Workaround

The issue disappears if the coefficient c is nonzero. Thus, one can skip terms c y when generating constraints by checking if the coefficient c is zero.

In the above example, calling problem.add_row(..1, &[(x, 1.)]) instead of problem.add_row(..1, &[(x, 1.), (y, c)]) works.

@lovasoa
Copy link
Contributor

lovasoa commented Aug 21, 2022

I fixed it by handling highs warnings as successes, just logging a warning. But the logs are quite useless at the moment, because there is no way to know what the problem was.

But @jajhall , it would be great if there was a way to programmatically access error messages from the C api, instead of trying to use side effects directly from inside HiGHS to perform IO. Something like Highs_errmsg, on the model of sqlite3_errmsg

@jajhall
Copy link
Collaborator

jajhall commented Aug 22, 2022

But @jajhall , it would be great if there were a way to programmatically access error messages from the C api, instead of trying to use side effects directly from inside HiGHS to perform IO. Something like Highs_errmsg, on the model of sqlite3_errmsg

Indeed, some system of retrieving the cause of the most recent error/warning message is planned. Thanks for the pointer

@evolutics
Copy link
Author

Thanks both for the quick reactions.

regular-citizen added a commit to regular-citizen/highs that referenced this issue Nov 9, 2022
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