[Coin-standards] Re: Sparse matrix representation

[Leonardo B. Lopes]

On Mon, 15 Apr 2002, Gus Gassmann wrote:

> None of the above, at least not quite: 
> Block storage. (Given my strong preference for decomposition 
> algorithms, I think this is inevitable. You also need to take the 
> matrix apart into the different time periods for many other functions.)

I agree with the blocks. In the SNOML proposal there is an explicit stage
concept, which is independent of SP. Of course you could choose to ignore
it and put everything in the first stage.

> For continuous distributions you ought to store the distributions 
> themselves in some suitable format; I haven't come up with a good 
> format. 

I tend to think that distribution information doesn't belong here, unless
it is in the nonlinear part. (Are we still talking of your SMPS extension,
or are we being more general and talking about both projects?). There are
two reasons: first, the interactions between different distributions seem
too specialized (in the general case) to be dealt with directly by solvers
anytime soon; second, the decisions about which distributions to choose,
which parameters, sampling granularity, etc... seem to me like modeling
issues and not instance issues. I think that might be the reason so many
smart people have looked at this and no one has come out with a real good
solution...


> (And of course if you have chance constraints, you need 
> something else again, and, and. Trouble is, there are so many 
> problem variations, and one format to fit all is going to be quite 
> complicated.

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.

> 
> > Remembering of course that we won't be performing inner products or
> > gaussian-type operations on these, but instead a lot of set unions and
> > intersections (at least in SMPS). 
> 
> This depends on the algorithm you use. If you have a 
> decomposition solver, you will very much compute inner products. 

I guess I am thinking that no matter what we do, people are going to want
to convert the data structures we give them to their own internal format.
They will need to do inner products, but we won't. Do you think we might
need to do inner products just as part of setting up the data structures?

> (Of course you are right: If you have a general purpose LP solver, 
> you will instead pull full columns out of the data structure for further 
> processing, so there will have to be a variety of support procedures, 
> too.)

Yes! This is an important point. The API/DOM *must* contain support
procedures that allow the same file to be viewed different ways.

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