-
Notifications
You must be signed in to change notification settings - Fork 40
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
Signomial Equality Constraints #234
Comments
I'm all for Posy Eq in SPs! At least, once @whoburg and I implement the inner loop for finding a feasible SP starting point that we discussed last Thursday. Right now they're almost guaranteed to be infeasible without a starting point guess. But we could start by just implementing them now, and only expecting them to work if you give a feasible initial guess. |
Yea, I'm ok with that. It's just easier to start my modeling with all |
Inline comments could help with that as well.
|
I suppose so, but if I have to do all my early modeling with |
How about: every line that should be an equality, you put "# should be an
equality" after.
|
I'm looking forward to helping with implementation of the inner SP solution heuristic (needed to make posynomial equality constraints work). Would be helpful to have a baseline sketch of the current algorithm (as requested in #207), which we can then modify and iterate on. |
@cjk12, if you have a simple minimum working example of an SP that involves a posynomial equality constraint, that would be helpful. (I will likely also have some examples myself, from working on the QPROP formulation). |
Unfortunately I don't at the moment, but I probably will in the near On Tue, Apr 28, 2015 at 8:19 AM, Warren Hoburg notifications@github.com
Cody J. Karcher |
Should I implement fake Posy EQ for now, or leave it be until it works? |
I'm fine with leaving it be. |
Yeah, I think we should wait on allowing posy equality constraints until we expect them to perform well. Don't want bad initial experiences to create prejudice against what will probably be a useful formulation. Technically, if someone has a feasible initial guess and knows what they're doing, they can create (as I understand it) what would have been fake Posy EQ by bounding both sides with signomial constraints, and specifying the feasible initial guess. But I think the best plan is to hold off for @bqpd and me to do a clean implementation. |
Isn't this the ticket that captures the need to "implement the inner loop for finding a feasible SP starting point that we discussed last Thursday", as well as exposing signomial/posynomial equality constraints to the user? Feel free to re-close if this is a duplicate. |
I wonder if we should call them signomial equality constraints, to further highlight the lack of solution guarantees. |
Ooh, I like that naming. Yeah this issue should probably remain open; I wrote up an algorithm draft over in #207. |
I propose closing this, duplicate of #397. |
SGTM |
So, I'd really like to be able to enforce a Posynomial Equality Constraint in SP's. I know this is a bad idea, but it is nice to have during model development. I propose two methods of implementing this:
Solution 1
Have the constraint:
x + y == z + w
automatically default within the code to:
x + y >= z + w
x + y <= z + w
And throw whatever nasty bold flags that @bqpd no doubt wants.
Solution 2
Enable some type of sandbox mode where I can do my early modeling that essentially has no guarantees, but will at least run implementing Solution 1. This may also be a good place to implement some of those 'pressure' or 'flow' tools that were discussed on Thursday.
I realize this may be controversial, so please feel free to discuss.
The text was updated successfully, but these errors were encountered: