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

Ompr v1 #349

Merged
merged 10 commits into from
Jan 6, 2022
Merged

Ompr v1 #349

merged 10 commits into from
Jan 6, 2022

Conversation

dirkschumacher
Copy link
Owner

Towards a new MIPModel. It is currently named MIPModel2.

This is a preparation for a new model backend.
Currently named MIPModel2. Still somewhat WIP
@sbmack
Copy link

sbmack commented Jan 6, 2022

Towards a new MIPModel. It is currently named MIPModel2.

Dirk, I am sort of confused. So MIPModel2 is a new branch from MIPModel with MILPModel being set aside? Is there a link with MIPModel2 formulation information and examples available for MIPModel2? Thanks, SteveM

@dirkschumacher
Copy link
Owner Author

Dirk, I am sort of confused. So MIPModel2 is a new branch from MIPModel with MILPModel being set aside? Is there a link with MIPModel2 formulation information and examples available for MIPModel2? Thanks, SteveM

Well, if everything works, there will be a new MIPModel which is near 100% backwards compatible. It won't affect MILPModel. As of right know, I would like to make that new version of MIPModel good enough also for larger models, such that we can deprecate MILModel. I believe the vectorized semantics just cause too many problems. But that is another discussion and not part of that PR.

@sbmack
Copy link

sbmack commented Jan 6, 2022

Well, if everything works, there will be a new MIPModel which is near 100% backwards compatible. It won't affect MILPModel. As of right know, I would like to make that new version of MIPModel good enough also for larger models, such that we can deprecate MILModel. I believe the vectorized semantics just cause too many problems. But that is another discussion and not part of that PR.

Thanks for the update. Agree about the problematic vectorized semantics in MILPModel. Ideally, an updated constraint function in MIPModel2 would accommodate sparse formulations, (row, column, value). I am not a developer, but it seems like the dplyr pivot_longer function could pre-process the sparse constraint set in rcv format and that could be passed to MIPModel2.

Again, appreciate your efforts. SteveM

It seems, everything should be backwards compatible.
Doing this we can also delete a lot of old code.
It has been fixed by the new MIPModel
Fixed by new MIPModel
Index ordering was not correct in `add_variable`.
@dirkschumacher
Copy link
Owner Author

dirkschumacher commented Jan 6, 2022

Ideally, an updated constraint function in MIPModel2 would accommodate sparse formulations, (row, column, value). I am not a developer, but it seems like the dplyr pivot_longer function could pre-process the sparse constraint set in rcv format and that could be passed to MIPModel2.

@sbmack can you elaborate a bit what you mean exactly? Ideally post that in the Ideas category of the discussions. Appreciate your input!

Especially important for larger models with lots of
variable instances.
First draft.
@dirkschumacher dirkschumacher marked this pull request as ready for review January 6, 2022 19:38
@dirkschumacher dirkschumacher merged commit 957bec7 into master Jan 6, 2022
@dirkschumacher dirkschumacher deleted the omprV1 branch January 6, 2022 19:41
@sbmack
Copy link

sbmack commented Jan 6, 2022

@sbmack can you elaborate a bit what you mean exactly? Ideally post that in the Ideas category of the discussions. Appreciate your input!

Thanks for the reply. Idea posted in the Ideas category of the Discussions section. SteveM

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