Feature: passing in nomimal values of uncertainties

[vgupta1]

So, what if JuMPeR supported setting "initial values" on uncertainties. These could be added, e.g., as certain constraints to "seed" the cut generation process. I'm thinking the interface could leverage the same "setValue" interface that warmstarts use in JuMP. E.g.

@defUncs(rm, u[1:2])
setValue(u[1], 0.0) #A nominal value for u
setValue(u[2], 1.0)

In the case where the user has multiple reasonable initial points maybe she could pass them as arrays (assuming that the ordering of the array corresponds to the same uncertainty across coordinates).

One advantage of this is it offers a way out of the need for adding the bounding box when starting cut generation; in reasonable problems, adding nominal values to uncertainties should make them well-behaved.

Thoughts?

[IainNZ]

This has been bugging me because I've needed this myself. I think you've hit on the problem here though - what if you have multiple points? In fact, this would be the common case I suspect, which might inform how it should be designed.

One API could be this

@defUncs(rm, u[1:2])
addScenario!(rm, [u[1] => 0.0, u[2] => 1.0])
addScenario!(rm, [u[1] => 1.0, u[2] => 0.0])

or

@defUncs(rm, u[1:2])
addScenario!(rm, [(u[1], 0.0), (u[2], 1.0)] )
addScenario!(rm, [(u[1], 1.0), (u[2], 0.0)] )

[IainNZ]

I have a different solution for the unboundedness issue

[vgupta1]

What about for setting initial cuts?

---

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

On Mon, Apr 21, 2014 at 12:14 AM, Iain Dunning notifications@github.comwrote:

I have a different solution for the unboundedness issue

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

[IainNZ]

Thats what I just wrote isn't it?

[vgupta1]

Sorry, Github emailing me sometimes garbles the order of messages. My fault entirely...

I like the addScenario using dictionaries... Constructing scenarios as arrays of tuples feels like it's going to be cumbersome. The idea of using setValue was just to try and mirror the nominal interface as much as possible, but I agree that there isn't a ton of upside in it. The addScenario description seems much more usable.

Could it be written in a way that one could call it from within generateCut????

[IainNZ]

It could... but I don't like it on first thought because it confuses the intent a bit... probably need to implement it and see how it feels.