Please check if the PR fulfills these requirements
[ ] The commit message follows our guidelines
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)
What kind of change does this PR introduce?
Bug fix
What is the current behavior?
MIP resolution can have unexpected behaviour (eg give out a suboptimal solution) when using too large numbers that do not exceed its own definition of infinity, or too small numbers that are not zero (because of scaling algorithms).
What is the new behavior (if this is a feature change)?
Now "infinity" value is defined solver-wise, and used where suitable. For instance, for XPRESS we should use 1e20 instead of 1e10.
Plus, maxTso & maxRa constraint is skipped for cases where the maxTso/maxRa value is too large (and useless), in order to avoid badly conditionned MIPs.
Also, using infinity showed there was a bug in or-tools v9.9, so we bumped up to v9.10.
Does this PR introduce a breaking change or deprecate an API?
Please check if the PR fulfills these requirements
What kind of change does this PR introduce?
Bug fix
What is the current behavior?
MIP resolution can have unexpected behaviour (eg give out a suboptimal solution) when using too large numbers that do not exceed its own definition of infinity, or too small numbers that are not zero (because of scaling algorithms).
What is the new behavior (if this is a feature change)? Now "infinity" value is defined solver-wise, and used where suitable. For instance, for XPRESS we should use 1e20 instead of 1e10. Plus, maxTso & maxRa constraint is skipped for cases where the maxTso/maxRa value is too large (and useless), in order to avoid badly conditionned MIPs. Also, using infinity showed there was a bug in or-tools v9.9, so we bumped up to v9.10.
Does this PR introduce a breaking change or deprecate an API?