[Coin-standards] SP Interface -- two levels?

[Leonardo B. Lopes]

> At the SMPS level, one may describe a continuous distribution whose value
> is revealed in a deterministic time interval.  We haven't worked out a
> general way of representing stopping times (ie stochastic time intervals).
> Let us call the first type a stochastic program with deterministic time
> increments (SPDT) and the second a stochastic program with stochastic time
> increments (SPST) --- whatever that is.

Actually the SPST case is something I have completely ignored so far. But
it is an interesting case. How about we start a new thread and try to
figure something out about that? I actually have a suggestion. With each
scenario, under each subproblem, we can associate an arbitrary nonlinear
expression (mathml?) that determines the stopping time. Maybe someone
would like to help make that feature more precise? 

> It seems that this state of affairs may require two levels of intermediate
> architecture.  Level SPI1 that supplies methods to communicate efficiently
> with solvers, and level SPI2 that supplies methods to communicate
> efficiently with SMPS and/or modeling environments.
> 
> This may be needed even in the simplest case of solving SPDT with L-shaped
> method.  For example, the L-shaped method in OSLSE doesn't much care what
> the distribution is so long as it looks like a scenario tree.  Managing the
> scenario tree data structure is quite a big job that could be done by SPI1.

I agree with with this division. SPI1 is similar to SMPS+access library or
to SNOML.

> One might take the view that SPI1 + "L-shaped method" is in fact an SPDT
> "solver" class, but I would argue that there is still so much work to be
> done in this space that it may be better to keep them separate at least
> until the community converges on the short list of the most useful methods.

I think that they should be separate, even though the argument that they
represent one case is reasonable. Some of the ways in which SPI1 would be
used in the context of an L-shaped method are sufficiently general and
well understood to be part of a library. In particular, obtaining blocks
from stage and scenario aggregations could be part of SPI1. They don't
really change the essence of an L-shaped method, so that is an argument
for having it in SPI1. OTOH, it would probably be more efficient to
perform aggregations in the solver's internal DS, which strengthens the
"solver class" argument. I'd say leaving it as part of SPI1 allows for
more generality.


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