-
Notifications
You must be signed in to change notification settings - Fork 2
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
Conversation
return constraint | ||
|
||
|
||
def _get_coefficients( |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes! For quadratic objectives!
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this 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( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me!
this is now ready @funkey
see funkelab/motile#30 for an example of how this could be used in motile