Skip to content

Add support for IntVar op constant RoutingSolver constraints, and remaining ops - #92

Open
willbryant wants to merge 2 commits into
ankane:masterfrom
willbryant:constant_constraints
Open

willbryant wants to merge 2 commits into
ankane:masterfrom
willbryant:constant_constraints

Conversation

@willbryant

@willbryant willbryant commented Sep 14, 2026

Copy link
Copy Markdown
Contributor

or-tools supports both IntVar op IntVar and IntVar op int64_t versions of each constraint-factory method. This PR implements that, using a template function to avoid having to write out the ops twice.

It also fills in the remaining ops defined in Expression and already supported by CpModel.

This is the warmup to what I personally need, which is IntVar - IntVar <= const, or more broadly arbitrary Expression support in RoutingSolver#add, which will be in the final PR.

That is supported in the Python wrapper, but not yet this Ruby wrapper.

NB. I've chosen to be explicit about Constant, because IntVar also responds-to #value, making it hard to duck type. Testing the convertibility of the argument to IntVar first is an option, but becomes quite awkward in that last PR when we support other Expressions. Letting RICE choose using C++ method overloading was the other option, which I tried in my first draft, but again that becomes problematic when trying to add Expression support as there is no type mapping (IntExpr* is the equivalent, but it isn't really possible to convert between Expression and IntExpr* using RICE because you need access to the Solver to register the expression, which doesn't fit the RICE type-conversion idiom).

tl;dr handling Constant specifically is best.

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

Successfully merging this pull request may close these issues.

1 participant