Re: Re [Help-glpk] variable object and deletions

[Yingjie Lan]

Hi Robbie,

> ------------------------------------------------------------
> >
> > Hi,
> >
> > Suppose you would like to use a variable object (a C
> > structure, or C++ class, or Python class, etc) to
> > represent a column in GLPK, it is probably natural to
> > let the variable object have an integer field called
> > 'index', which is the index of this variable in the
> > GLPK model (the API of GLPK use this index very
> > often). But there is a problem: when you delete a
> > variable, you must update all this field for all
> > variables behind the deleted variable. I am also
> aware
> > of another index, which is the name of each variable,
> > but it is less efficient (probably OK if doing
> > Python). I wonder if there is a more elegant way to
> > implement a variable object that would significantly
> > brings down the overhead involved with variable
> > deletions. Similar problem can be proposed for
> > constraints, of course, and I suspect the solution is
> > similar too.
> >
> > Regards,
> >
> > Yingjie
> 
> I assume this is during problem building and prior to
> loading the data into a GLPK problem object?  For
> C++:
> 

Yes, the index value is assigned at that time, when
you add the column (variable) into the GLPK model.
The deletion comes from the use case when you are
modifying the model (some customized algorithms 
may need to delete some non-basic variables from
the model). 

> What if you hold your columns in std::list<Column>
> rather than std::vector<Column>?  Easier to
> delete
> entries in the way you wish I would think.
> 

OK. The position index of the column in the list is
used to make calls to GLPK API routines. When you 
delete one column from your list (where you must
also have deleted the same column from the GLPK model), 
the position of those columns after the deleted column
in the list/model also changed (reduced by 1). How
to efficiently keep track of this index change is 
my problem.

> I haven't got any C++ books here, otherwise I would
> work this up a bit more.
> 
> Berryhill will undoubtedly have some good suggestions
> on the design of optimization problem structures:
> 
>   Berryhill, John B.  2001.  C++ scientific
> programming :
>     computational recipes at a higher level John
> Wiley and
>     Sons, New York, USA.  ISBN
> 0-471-41210-4.
> 
> hope this is on the right track

Thanks, Robbie. Will check it out when got a chance.

Yingjie