[Coin-standards] Re: Sparse matrix representation (fwd)

Leonardo B Lopes leo at iems.nwu.edu
Fri Jul 5 17:25:49 EDT 2002


Hi Dr. Gassmann,

	I hope you don't mind if I reply to the list. This is an important item.

	I agree that the situation you describe is very important. The answer to 
your question in the context of SNOML is that there are actually two 
distinct elements, <row> and <rowset>, which have different semantics. 
Simply declaring a <row> does not make it a constraint. A reference to 
the <row> must appear in a <rowset>, and the probability is a property 
of the <rowset>, not of the <row>. The main reason for this choice was 
precisely the problem you described, but separating the two also allows 
for a more concise and structure-rich representation of structures which 
repeat themselves.

Cheers,
Leo.

Gus Gassmann wrote:

> Hi Leo,
> 
> here is another one that I have finally rediscovered recently. 
> Somehow I never replied, I think:
> 
> 
>>The alternative would be to represent that constraint by flagging (or
>>not) an element of the linear part as randomly distributed, and
>>providing a distribution at some other point (like SMPS), or including
>>the distribution info there (which is possible), which would make
>>those expressions nonlinear anyway...
>>
>>
>>>>Actually, I think there might be a relatively elegant way of
>>>>communicating chance constraints. In SNOML there are <rowset> tags
>>>>with probability parameters, which default to 1.
>>>>
>>>That's a start, but I don't see (off-hand) how you can model multi-
>>>dimensional chance-constraints in this fashion. 
>>>
>>>
>>Chance constraints, whether single or multidimensional, are handled in
>>snoml (as of now) by specifying the "prob" attribute of a <rowset>. So
>>if the <rowset> includes more than one row, all those rows are taken
>>together to have probability p. If they are linear, or nonlinear, it
>>doesn't really change the syntax either.
>>
> 
> I have thought about this a bit, and I don't see how it can work. For 
> instance, how would you deal with rows that are actually subject to
> more than one chance constraint at a time? This may seem wild, 
> but think of a two-stage transportation/allocation problem where 
> you have demand constraints (with random demands) in several 
> locations:
> 
> sum {s in SOURCES} transp[s,d] >= Demd[d]   for  d in DEST
> 
> You then want 
> 
> Prob{Allocation[d] >= Demd[d]} > alpha[d] for all d 
> (e.g., alpha[d] = 0.95)
> 
> and also
> 
> Prob{Allocation[d] >= Demd[d] for all d} > alpha
> with alpha, say, 0.80.
> 
> This strikes me as a fairly natural thing to want.
> 
> 
> 
> -------------------------------------------------------
> 
> gus gassmann          (Horand.Gassmann at dal.ca)
> 
> School of Business Administration, Dalhousie University
> Halifax, Nova Scotia, Canada , B3H 1Z5
> ph. (902) 494-1844
> fax (902) 494-1107
> 
> http://www.mgmt.dal.ca/sba/profs/hgassmann/
> 


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




More information about the Coin-standards mailing list