[Coin-discuss] Osi and Add/Delete rows

Matthew Saltzman mjs at ces.clemson.edu
Fri Nov 4 09:38:53 EST 2005


On Fri, 4 Nov 2005, Jonathan Eckstein wrote:

> In developing PICO, which uses OSI, we assume the behavior you describe and 
> use a splay tree data structure to track the row numbers.  When we insert a 
> row, it gets a unique ID by incrementing a counter.  The splay tree can 
> quickly calculate the cardinality of any value in the set of currently loaded 
> rows, and that gives its position within the solver.
>
> But since I am not an OSI or solver author, I cannot speak with complete 
> authority.

This is one of those situations where "solver agnosticism" creates a 
potential for ambiguity in OSI behavior.  Ultimately, the addRow() and 
deleteRow() calls are implemented via calls to the specific solver's row 
management functions.  So the rules for renumbering are actually 
solver-specific.

On the other hand, as far as I am aware, all the solvers involved behave 
as described (append at the end, delete and renumber in order).

>
>  -- Jonathan
>
>
> Jan-Willem Goossens wrote:
>
>> Hi all,
>> 
>> I have a question about adding and deleting rows through the
>> osisolverinterface layer.
>> 
>> I start with loading my problem with loadProblem. After that, of course,
>> the actual adding or deleting of a row is no problem; just calling addRow
>> or deleteRow works fine.
>> 
>> My problem is with the offsets (index numbers) of the old and new rows.
>> Since I can only retreive, for example, price info for a particular row
>> with getRowPrice() if I know the index of the row I'm interested in, it's
>> crucial that, in case of some deleted rows, I can update my recorded index
>> numbers.
>> 
>> One way for me to do this accounting would be to assume that if I remove
>> row i, then all rows j > i will all be moved 'back' one position. But this
>> would depend on the implementation of the deleteRow on the solver-specific
>> side. For additions, I guess it's OK to assume they will be added 'at the
>> end'.
>> 
>> Or is there a completely different way around this problem?
>> 
>> Thanks in advance,
>> 
>> Jan-Willem
>> 
>> 
>> _______________________________________________
>> Coin-discuss mailing list
>> Coin-discuss at list.coin-or.org
>> http://list.coin-or.org/mailman/listinfo/coin-discuss
>
> _______________________________________________
> Coin-discuss mailing list
> Coin-discuss at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/coin-discuss
>

-- 
 		Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs



More information about the Coin-discuss mailing list