[Coin-discuss] OsiStochSolverInterface -- initial objective and outline

[Alan King]

Hi Leo

Your note raises a number of very good issues.  I'm not sure I have all 
the answers here, but let me have a go.

The key issue I'm concerned about here is data management.  Parsing 
incoming scenario data into matrix blocks, and then copying the result 
into data regions managed by the tree object involves a lot of overhead. 
It seems better to put the incoming data directly into the solver, and 
keep track of it using the extra information provided by labels.

It could be implemented by deriving a class from OsiSolverInterface with 
new methods like:
OsiStochSolverInterface::loadScenario( scenarioID, LPData)
{
        rowOffsetByLabel = getRowOffsetByLabel(scenarioID);
        colOffsetByLabel = getColOffsetByLabel(scenarioID);
        addColsWithLabelOffsets(LPData,colOffsetByLabel);
        addRowsWithLabelOffsets(LPData,rowOffsetByLabel);
}
OsiStochSolverInterface::getScenarioPrimalSolution(scenarioID)
{
        labels = getColLabels(scenarioID);
        return extractColSolutionByLabels(labels);
}

There is a reasonable data/method encapsulation emerging here.  The 
methods addXXXWithLabelOffsets() and extractXXXByLabels() naturally belong 
to a class that could be used for things other than stochastic --- eg for 
modeling languages to interface with solvers that can take advantage of 
model substructures.  The "labeled" methods may in fact be useful enough 
to include in the base OsiSolverInterface class, and implementations may 
find themselves rewarded by devoting some effort to making such methods 
efficient and useful.

Finally, many stochastic processes have a quite compact description that 
can be managed independent of a scenario tree, and there are solution 
procedures that never have to form a scenario tree.  In fact, given the 
curse of dimensionality, one would like to avoid having to form a scenario 
tree at all...

Anyway, these are my thoughts at the moment.  Still many details to be 
worked out.

Best,
Alan


Alan King
http://www.research.ibm.com/people/k/kingaj/
Mathematical Sciences Department
IBM Thomas J. Watson Research Center
(914) 945-1236, 8-862-1236




Leonardo B Lopes <leo at iems.northwestern.edu>
Sent by: coin-discuss-admin at www-124.southbury.usf.ibm.com
02/25/2003 07:20 PM
Please respond to coin-discuss
 
        To:     coin-discuss at www-124.southbury.usf.ibm.com
        cc: 
        Subject:        Re: [Coin-discuss] OsiStochSolverInterface -- 
initial objective and outline


I think I have a different alternative we might want to look at. But 
first let me make sure that I understand your proposal correctly. Say we 
have the following scenario tree (if you cant see it correctly change to 
fixed-width fonts):

A--------A---------A
  \        \
   \        --------B
    \
     -----C---------C
           \
            --------D
             \
              ------E

Are you proposing then that we name things buy[A,1] (1 is the stage) and 
then have methods which would return, for example, all the variables 
containing the string "A,1"?

How about having a Scenario Tree defined in the class Hierarchy 
somewhere? This tree would contain essentially an LP at every node, as 
well as a reference to some previous stage LP and a matrix (a Technology 
matrix in SP-speak) connecting this previous stage LP to the current LP. 
Possibly, the matrices themselves might have a composition mechanism by 
which one matrix can be produced from another similar one, similarly to 
the SMPS specification. The composition mechanism is useful even outside 
SLP.

The main result of this design would be to move all the "A,1" labels 
from the variables themselves to the node containing them.

Coments?

Alan King wrote:
> 
> Hello folks
> 
> Want to share a couple thoughts on the stochastic project and get your 
> permission to begin entering code into COIN.
> 
> Our first objective will be to write a simple set of interfaces that 
> allow users to input scenario data, solve, and extract solution data "by 

> scenario".  We'll derive an OsiStochSolverInterface base class from 
> OsiSolverInterface, and then provide an implementation or two (OSLSE and 

> CLP). 
> 
> Unless there are strenuous objections, it seems to make sense to proceed 

> as follows:
> 1) introduce row/column labels into the base OsiSolverInterface 
> (defaults to string returning NULL) and develop a bunch of sort/extract 
> by label utilities.
> 2) base the stochastic information management in OsiStochSolverInterface 

> on the label utilities (in stochastic programming the labels correspond 
> to nodes of the scenario tree).
> 
> How do I get write permission?
> 
> Best,
> Alan
> 
> Alan King
> http://www.research.ibm.com/people/k/kingaj/
> Mathematical Sciences Department
> IBM Thomas J. Watson Research Center
> (914) 945-1236, 8-862-1236

-- 
=======================================================================
Leonardo B. Lopes                                      leo at iems.nwu.edu
Ph.D. Candidate                                           (847)491-8470
IEMS - Northwestern University             http://www.iems.nwu.edu/~leo

_______________________________________________
Coin-discuss mailing list
Coin-discuss at www-124.ibm.com
http://www-124.ibm.com/developerworks/oss/mailman/listinfo/coin-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/coin-discuss/attachments/20030225/3292a86c/attachment.html>