Signomial Equality Constraints

[codykarcher]

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.

[bqpd]

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.

[codykarcher]

Yea, I'm ok with that. It's just easier to start my modeling with all == than >=. If I see a == I'll try to fix it, but I may assume that the >= is correct and not come back to it...

[bqpd]

Inline comments could help with that as well.

[codykarcher]

I suppose so, but if I have to do all my early modeling with #fix at the end of each line, it will become a little tiresome...

[bqpd]

How about: every line that should be an equality, you put "# should be an equality" after.

[whoburg]

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.

[whoburg]

@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).

[codykarcher]

Unfortunately I don't at the moment, but I probably will in the near future. The wing aerodynamics problem is a little too big for this application.

On Tue, Apr 28, 2015 at 8:19 AM, Warren Hoburg notifications@github.com wrote:

@cjk12 https://github.com/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).

— Reply to this email directly or view it on GitHub https://github.com/convexopt/gpkit/issues/234#issuecomment-97041467.

Cody J. Karcher Graduate Student Department of Aeronautics and Astronautics Massachusetts Institute of Technology

[bqpd]

Should I implement fake Posy EQ for now, or leave it be until it works?

[codykarcher]

I'm fine with leaving it be.

[whoburg]

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.

[whoburg]

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.

[whoburg]

I wonder if we should call them signomial equality constraints, to further highlight the lack of solution guarantees.

[bqpd]

Ooh, I like that naming.

Yeah this issue should probably remain open; I wrote up an algorithm draft over in #207.

[whoburg]

I propose closing this, duplicate of #397.

[bqpd]

SGTM