-
-
Notifications
You must be signed in to change notification settings - Fork 394
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
Nonlinear subexpressions #3738
Comments
@variable(model, y)
@constraint(model, y :== f(x)) |
What is stopping |
Yes, it's a breaking change. We discussed this on the monthly developer call. @mlubin is in favor of looking into a |
Some related discussion from jump-dev/MathOptInterface.jl#2488: Some possible options:
I don't have a strong opinion yet. But our current approach requires us to smack the modeler on the hand and tell them they're holding it wrong and that they should do (2): #3729 (comment) |
Background
@NLexpression
.MOI.Nonlinear
has support for representing expressions, and dealing with them efficientlyScalarNonlinearFunction
, we did not create an analogousScalarNonlinearExpression
object.@NLexpression
, or they made every possible expression a@NLexpression
The question is how to achieve this in JuMP.
I opened an issue in MOI: jump-dev/MathOptInterface.jl#2488
Short of rewriting much of the
MOI.Nonlinear
module to use a single DAG of expressions (instead of the current tree), we could pass the expressions through to MOI, and then attempt to detect common subexpressions. This would rely on a heuristic of when it was beneficial to do so.A simpler approach would be to add a "nonlinear expression" set to MOI (and JuMP), just like we've done for Parameter.
A crude API would be:
with the fallback to a bridge
and maybe one for MCP:
We could come up with nicer syntax, for example:
The text was updated successfully, but these errors were encountered: