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

Add expression objects, convertible to LinearConstraints #9

Merged
merged 17 commits into from
Mar 24, 2023

Conversation

tlambert03
Copy link
Member

@tlambert03 tlambert03 commented Mar 15, 2023

this is now ready @funkey

from ilpy import Relation
from ilpy.expressions import Variable

u = Variable("u", index=0)
v = Variable("v", index=1)
e = Variable("e", index=2)

expr = 2 * u - 5 * v + e / 2 >= -3
print(expr)  # "2 * u - 5 * v + e / 2 >= -3"

constraint = expr.constraint()
assert constraint.get_value() == -3
assert constraint.get_relation() == Relation.GreaterEqual
assert constraint.get_coefficients() == {0: 2.0, 1: -5.0, 2: 0.5}

see funkelab/motile#30 for an example of how this could be used in motile

@tlambert03 tlambert03 changed the title starting on expressions Add expression objects, convertible to LinearConstraints Mar 16, 2023
return constraint


def _get_coefficients(
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would appreciate a careful look at this function... which is responsible for reducing an expression to coefficients (even if a term appears multiple times or is nested inside parentheses)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me!

e = expr.right
v = expr.left.value
else:
# XXX: will we ever need multiplication by a variable?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes! For quadratic objectives!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, I thought so. that raises another question: should the Expression.constraint() method be renamed to linear_constraint()? or should it simply be smart and return the right type of constraint given the expression? (i.e. autodetect whether it's a quadratic expression)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also, do you want that done in this PR? or should I switch it to a NotImplementedError for now and follow up in another PR?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NotImplementedError is totally fine for now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd keep the constraint() instead of linear_constraint(). Future versions might return either, no need for the user to specify it.

Copy link
Member

@funkey funkey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wonderful, I like it very much!

Only problem I have with it is that I want more of it now :)

Those are the things we could build on top of the expressions:

  • conversion of expressions into objectives
  • support for quadratic objectives (and maybe at some point quadratic constraints, which are not part of the C++ wrapper, yet)
  • definitions of ranges (0 <= x <= 10 could be allowed)
  • support for boolean expressions (x > 0 and y == 1 = z)

...but this is out of scope for this PR I'd say.

return constraint


def _get_coefficients(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me!

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.

2 participants