search

dwavesystems / dimod

A shared API for QUBO/Ising samplers.
https://docs.ocean.dwavesys.com/en/stable/docs_dimod/
Apache License 2.0
121 stars 80 forks source link

Keeping constraint labels when converting cqm to bqm #1026

Open ozlemsalehi opened 2 years ago

ozlemsalehi commented 2 years ago

Application Currently, when one converts a cqm to bqm, labels of the constraints are discarded and generated from scratch, resulting in slack variables with the new label. Also, in case a warning is given, it is given with the new label making it impossible to understand for which constraint it is about.

Proposed Solution Instead of generating them from scratch, old labels can be kept, which will make easier issues mentioned above.

arcondello commented 2 years ago

So I think there are a few cases that we should distinguish: 1) quadratic constraints - not currently supported by cqm_to_bqm :heavy_check_mark: 2) linear inequality constraints - it would be straightforward to use the constraint label in the name of the new slack variables and in error messages :heavy_check_mark: 3) linear equality constraints - there are no new slack variable to apply the constraint labels to, what behavior would make sense in this case?

As denoted by the :heavy_check_mark: I think (1) and (2) are fine, but it's not clear to me what the ideal behavior for (3) would be. A decision on (3) does not block working on (2) though.

ozlemsalehi commented 2 years ago

In case 3, even though there are no slack variables, there might still be some warnings about the constraint in which case it is better to use the actual label in my opinion. Currently no such warnings are given in case of equality but in the future they can be implemented. (For instance if the constraint is not feasible for any assignment of values)