Changes between Version 14 and Version 15 of osi2


Ignore:
Timestamp:
Mar 20, 2007 11:00:46 AM (15 years ago)
Author:
mjs
Comment:

Moved OSI2 to its own Trac page

Legend:

Unmodified
Added
Removed
Modified
  • osi2

    v14 v15  
    22= OSI2 Discussion =
    33
    4 
    5 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.
    6 
    7 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.
    8 
    9 2. 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.
    10 
    11 3. Finally, we call the ''modify()'' method for each class and do the modifications before solving.
    12 
    13 4. 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.
    14 
    15 
    16 5. I would like to avoid the terminology !OsiModel. We are working with problem instances and not models.
    17 
    18 6. Perhpas we should have class !OSSolver or !OsiSolver (these correspond to what Lou is calling !OsiModel) that has members of the following type:
    19 
    20 OSInstance
    21 
    22 OSInstanceMod
    23 
    24 OSResult
    25 
    26 OSOption
    27 
    28 OsiXFormRec
    29 
    30 OsiXForm
    31 
    32 7. 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.
     4OSI2 development activities have moved to https://projects.coin-or.org/Osi2.  The contents of this page are now at https://projects.coin-or.org/Osi2/wiki/Osi2Discussion.