-
Notifications
You must be signed in to change notification settings - Fork 528
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
Piecewise Linear transformations: Logarithmic and nested inner GDP representation #3036
Conversation
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.
Really cool PR!
Just saw a couple of typos! The interesting part would be the benchmarking once this is merged
Fixed typos and some other minor issues. |
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.
This is looking quite good!
This should be ready now. The linux/3.12 test failure seems to be spurious. |
pyomo/contrib/piecewise/tests/test_disaggregated_logarithmic.py
Outdated
Show resolved
Hide resolved
pyomo/contrib/piecewise/transform/disaggreggated_logarithmic.py
Outdated
Show resolved
Hide resolved
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.
A few comments, but this is looking quite good! My only concern is if there are tests that are common to multiple transformations, we should centralize them so that if things change in the future we only have to make changes in one place.
pyomo/contrib/piecewise/tests/test_disaggregated_logarithmic.py
Outdated
Show resolved
Hide resolved
pyomo/contrib/piecewise/tests/test_disaggregated_logarithmic.py
Outdated
Show resolved
Hide resolved
# Check one disjunct for proper contents. Disjunct structure should be | ||
# identical to the version for the inner representation gdp |
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.
For this and the others that are identical to the inner representation GDP, can we put these methods in the common_tests and just check them in both?
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.
It wouldn't really be appropriate for common_tests, since that file is also used for other transformations that are not inner representation-related. We could do this by moving the methods into a superclass between unittest.TestCase and the transformation test class, but I feel like that's unnecessarily complex to only house two duplicated methods. Well, we could start moving the test method boilerplate into the superclass too, but then it becomes inconsistent with the other transformations that have all their test methods duplicated.
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.
Maybe lets not convolute the class structure any more--I agree that that's not worth it, but could we move the methods themselves into functions in common_tests (or make a short common_inner_repn_tests
script if you prefer), and just make this method call that function? I do this in GDP a lot: my convention is to name the function check_whatever
, have its first argument be the test class (self
) and then in the test_whatever
method, I just call check_whatever
. Sorry to be picky, but maintaining tests in code that could potentially change a lot is really hard, and I think having it be very clear to future us what we expect to be common will be nice. :)
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.
That works. I've moved the methods to a common_inner_repn_tests file.
pyomo/contrib/piecewise/transform/disaggreggated_logarithmic.py
Outdated
Show resolved
Hide resolved
pyomo/contrib/piecewise/transform/disaggreggated_logarithmic.py
Outdated
Show resolved
Hide resolved
…ify variables mode does not work, gives infeasible models
…e it isn't GDP-specific
Oh... oops. I seem to have done something strange with git. One minute.. |
a384784
to
423dbf8
Compare
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!
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3036 +/- ##
==========================================
- Coverage 88.39% 86.55% -1.85%
==========================================
Files 847 849 +2
Lines 95263 95405 +142
==========================================
- Hits 84212 82582 -1630
- Misses 11051 12823 +1772
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
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 think this looks good. I went ahead and changed the one thing that was bothering me (converting int
to binary vectors without going through strings)
Fixes # .
Summary/Motivation:
We want to add piecewise-linear to GDP and to MIP transformations from Vielma 2010 so they can be used in Bashar's PWL representations paper.
Changes proposed in this PR:
Legal Acknowledgement
By contributing to this software project, I have read the contribution guide and agree to the following terms and conditions for my contribution: