[Coin-osi-devel] Next release of Osi

Matthew Saltzman mjs at ces.clemson.edu
Mon Nov 20 15:05:46 EST 2006


On Mon, 20 Nov 2006 fmargot at andrew.cmu.edu wrote:

>
> Similar methods for OsiXprSolverInterface and extension of that
> class are necessary for the new cut generator to work with Xpress
> too. Pierre has some "personal" code for it.

OK.

I'm more interested in methods that need to be in the base class to cover 
extensions in OsiXxxSI classes.  I'd be inclined to treat implementations 
of derived methods in OsiXxxSI classes as patch-level improvements rather 
than minor-number improvements.  They don't really change the API--they 
just make it work better.

 		Matt


>
> Francois
>
>
> On Mon, 20 Nov 2006, Matthew Saltzman wrote:
>
>> On Mon, 20 Nov 2006 fmargot at andrew.cmu.edu wrote:
>> 
>>> 
>>> They are right now in 
>>> Osi/branches/devel/Osi/src/OsiClp/OsiClpSolverInterface.cpp
>> 
>> So they extend the OsiSolverInterface class rather than overriding virtual 
>> methods in that class.
>> 
>> SIs can do that, but in principle, it's probably better to have the virtual 
>> methods and have them do something striking when not overridden.
>> So I don't think it's a bad idea to add these to OsiSolverInterface.  If 
>> other SI developers agree, the release planning questions are:
>> 
>> - Are there other methods that need this treatment?  We should get as many 
>> as possible pulled in at once, rather than bringing them in in dribs and 
>> drabs.
>> 
>> - I suppose these changes would warrant a minor rev level increment rather 
>> than a pach-level increment, i.e., these go in 0.96.0.  They change the 
>> API, but they should not break backward compatibility.
>> 
>> - Are there other relatively straightforward things that we ought to do at 
>> the same time?
>> 
>> 
>>> 
>>> Francois
>>> 
>>> On Mon, 20 Nov 2006, Laszlo Ladanyi wrote:
>>> 
>>>> Those can't be in Osi... A solver may not have a basis... Well, maybe 
>>>> they can
>>>> be... bu then the implementation in the base class needs to throw an 
>>>> exception
>>>> and if the solver overrides the methods then they should be able to do it
>>>> properly.
>>>> 
>>>> Otherwise... It's a question for Matt. And me. And John forrest. I'll 
>>>> talk to
>>>> John soon about how stable he thinks the branching stuff in Osi is.
>>>> 
>>>> --Laci
>>>> 
>>>> On Mon, 20 Nov 2006 fmargot at andrew.cmu.edu wrote:
>>>> 
>>>>> Is there a new release of Osi planned soon? If possible, I would like
>>>>> the two methods from OsiClpSolverInterface
>>>>> 
>>>>> virtual void getBInvARow(int row, CoinIndexedVector * z,
>>>>>                           CoinIndexedVector * slack=NULL,
>>>>>                           bool keepScaled=false) const;
>>>>> 
>>>>> and
>>>>> 
>>>>> virtual void getBInvACol(int col, CoinIndexedVector * ver);
>>>>> 
>>>>> to be in the next release. The new Lift-and-Project cut generator needs
>>>>> it and I can not make a new release of Cgl with a dependence on 
>>>>> Osi-devel.
>>>>> 
>>>>> Francois
>>>>> _______________________________________________
>>>>> Coin-osi-devel mailing list
>>>>> Coin-osi-devel at list.coin-or.org
>>>>> http://list.coin-or.org/mailman/listinfo/coin-osi-devel
>>>>> 
>>>> 
>>>> 
>>>> 
>>> _______________________________________________
>>> Coin-osi-devel mailing list
>>> Coin-osi-devel at list.coin-or.org
>>> http://list.coin-or.org/mailman/listinfo/coin-osi-devel
>>> 
>> 
>> 
> _______________________________________________
> Coin-osi-devel mailing list
> Coin-osi-devel at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/coin-osi-devel
>

-- 
 		Matthew Saltzman

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



More information about the Osi mailing list