Design Suggestion: Oracle Helper Fcns

[vgupta1]

Neglecting constant terms and standalone uncertainties, a general linear uncertain constraint can be written this way:
\sum_{i=1}^d a_i( u ) x_i \leq b
for some affine functions a_i, or equivalently, by rearranging terms as
\sum_{i=1}^d l_i( x )^T u \leq b

for some different affine functions l_i. As far as I understand, the first representation is (roughly) how they're stored in FullAffExpr. The "roughly" part comes because you don't necessarily need to group together all the terms depending on x_i.

In the course of the polyhedral oracle (and the bertsimas sim oracle), there's some general boiler plate code that I think MOST oracles need to do, and could be factored out, namely

• Convert representation 1 into representation 2
• Use the current x^* to evaluate the coefficients of representation 2
• After obtaining a u^*, use it to generate a cut for the original constraint. This depends on the sign of the constraint and needs to handle the constants on both sides correctly.

I suggest we factor out these functions into standalone helpers ( I can help! ) and then add one additional function which, given any uncertain constraint, converts it into a constraint in standard form (e.g. a less than or equal with all terms on lhs and all constants on rhs). In that way, we can write a templatized boilerplate (maybe even using parametric types?) user-defined oracles where all the user would need to implement is the solution to:

max_{u in U} u^T x^*

I can spell out more of what I'm thinking in person, but I'd like to get a conversation going on this... I really think it would limit how much users need to know about JuMPeR internals and simplify some of the steps in oracle creation.

[IainNZ]

This is very on my mind, and indeed #2 was me capturing that though. So we are definitely on the same page. I actually think its pretty exciting how the polyhedral specific part of PolyhedralOracle (apart from the setup) is realllly short.

[vgupta1]

Ok, so that's what that meant. :) The original issue was a bit cryptic. :)

A related worry that sparked this line of thought was that although
defining UncertainConstr as GenericRangeConstr and type aliasing is
elegant, it leads to potentially confusing code like accessing UAffExpr via

unc_constraint.coeffs[1]

(in my mind, coeffs are floats, but maybe i'm just old-fashioned.)

For people new to JuMPer, this is definitely a weird gotchya. Not
something that a researcher wants to have to decipher in order to code up a
custom oracle. Possibly unrelated. to this thread.

---

Vishal Gupta
PhD Candidate, 2014
Operations Research Center
Massachusetts Institute of Technology
www.mit.edu/~vgupta1/

On Sun, Apr 20, 2014 at 11:33 PM, Iain Dunning notifications@github.comwrote:

This is very on my mind, and indeed #2https://github.com/IainNZ/JuMPeR.jl/issues/2was me capturing that though. So we are definitely on the same page. I
actually think its pretty exciting how the polyhedral specific part of
PolyhedralOracle (apart from the setup) is realllly short.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/26#issuecomment-40913942
.

[IainNZ]

Yeah so in the beginning:

UAffExpr - coeffs, uncs
FullAffExpr - coeffs::Vector{UAffExpr}, vars

then I made FullAffExpr make use of GenericAffExpr which cut down on code (and thus chances for bugs).

Finally, I changed recently the UAffExpr to also be a GenericAffExpr to cut down code any more - but at the cost of losing uncs and changing it to vars. I'm happy with coeffs but vars kind of hurts. I'm hoping that the helper functions will eventually wrap this to the point where even oracle developers don't need to touch JuMPeR-specific stuff like this.

[IainNZ]

Fixed to my satisfaction for now, need to let whats there sit and see how it feels