OSI2 Discussion

Here are some comments on Lou's notes. Lou's pdf file is at the bottom of the page. It also includes a summary of comments from Jun in an earlier email. I also have some sample code attached at the bottom of the page.

  1. I like Lou's idea of an OsiXForm that provides one portion of the API. In the attached code below, osiTest.cpp, there is an abstract class OsiXForm which implements Lou's thinking (I think). This purpose of this virtual class is to provide a template for all classes which implement a problem modification. In this code I am using the "Command" design pattern where a modification method is encapsulated as an object. Each modification method is encapsulated into an object in a class that inherits from the abstract OsiXForm class. I provide two trivial examples, DeleteConstraints and AddVariables. The abstract class OsiXForm has two pure virtual functions record() and modify(). The record() method keeps track in a static vector all of the modifications of a given object type (for example the DeleteConstraints object). Before the problem is solved the modify() is called to make the necessary modifications for each class. Terminology -- I tend to use the word modification, Lou tends to use transformation. We should decide on a coinvention.
  1. Lou also suggested a way to record all of the transformations. Using his terminology there is a class OsiXFormRec. This class also has a record() method, however, the record() method in the OsiXFormRec class records ALL of the modification objects of every type into a vector modObjects. Then the OsiXFormRec class also has a method callModClasses(). This method loops over the vector modObjects of ALL types of possible modifications and by polymorphism calls the right modification class record() method. So the effect is now for each class to have a recording of all modifications specific to that class. So for example, the AddVariables would now have a complete list of variables that it is supposed to add.
  1. Finally, we call the modify() method for each class and do the modifications before solving.
  1. We may wish to have a class OSInstanceMod that inherits from OSInstance. This class would have all of the get() and set() methods from OSInstance plus the methods that actually do the modification.
  1. I would like to avoid the terminology OsiModel. We are working with problem instances and not models.
  1. Perhpas we should have class !OSSolver or OsiSolver (these correspond to what Lou is calling OsiModel) that has members of the following type:







  1. See the main() method in the attached cpp file below. It illustrates creating some problem modification objects, queuing them, allocating them to the appropriate classes, and then run the modify method.
Last modified 13 years ago Last modified on Mar 20, 2007 10:37:48 AM

Attachments (6)

Download all attachments as: .zip