[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