[Coin-discuss] Reset (was OsiOsl bug ?)

[Tim Hultberg]

>From my simple user point of view, things which are explicitly set different 
than the default via the OSI interface should be kept round loadProblem and 
nothing else. But I imagine that there are good reasons for this not being 
so.

Anyway I can now do what I want with the reset function. However what I really 
wanted to be able to do, and still cant, is to use the problem modification 
methods (f.ex setObjCoeff) for MIP problems. I realize that in the case of 
MIP there will not be any advantage in terms of execution speed by using 
problem modification instead of a reset followed by loading the modified 
data, but it would make implementation of problem modification within FLOPC++ 
easier not having to implement to different shemes. (Alternatively I could 
prohibit the use problem modifacation for MIPs)

Tim Hultberg


PS  I just downloaded the lastest tarball (2June), which broke anything with 
this error (even for pure LPs):
Program received signal SIGSEGV, Segmentation fault.
0x4037a153 in OsiClpSolverInterface::setInteger (this=0x809d050, indices=0x0,
    len=1072693248) at OsiClpSolverInterface.cpp:803
803         integerInformation_[indices[i]]=1;

(Same thing with Osl and Glpk)


On Friday 30 May 2003 19:08, John J Forrest wrote:
> Tim,
>
> It would be very tricky to decide what should be kept round loadProblem -
> e.g. should minimization be kept.  If nothing is kept then it should be a
> constructor.
>
> As you say the one clean solution is to have a base empty model which has
> settings you want to keep e.g. minimization and then clone from that.
>
> However this may not always be best solution.  Laci suggested that we add
> a "reset" function to interfaces which would set back as if default
> constructor.  It would not involve any more coding as the current default
> constructor coding would be copied to reset() and the default constructor
> just call reset.
>
> Comments?
>
> John Forrest

-- 

Tim Hultberg