[Coin-discuss] OsiCbc

[Alan King]

Few comments below
 

coin-discuss-bounces at list.coin-or.org wrote on 04/05/2005 07:43:00 PM:

> John J Forrest wrote:
> > 
> > Ted,
> > 
> > Does adding #include <cstdio> at top of CoinHelperFunctions.hpp help?
> > 
> > John
> 
> Yes, that fixes it. Thanks.
> 
> Also, the OsiSymSolverInterface unit test should work properly now. 
> There was a bug in the copy constructor that is now fixed. Also, I had 
> to comment out a few tests. SYMPHONY will not pass the common unit tests 

> for two reasons:
> 
> 1. We do not allow an infeasible solution to be loaded into the 
> interface. I think this is a reasonable policy, since it is natural to 
> assume that the currently loaded solution is feasible to the currently 
> loaded problem. SYMPHONY has no mechanism for storing an infeasible 
> solution. This unit test requires this. I'm not sure this is reasonable, 

> but I'd be curious to hear other opinions.

If the user can modify the loaded solution, then it is reasonable to 
assume
that it could be infeasible.

> 
> 2. Pointers to rim vectors returned by methods such as getColLower() 
> become invalid if the problem is modified. This is because SYMPHONY 
> itself returns a copy of requested rim vectors to the interface (not a 
> pointer to the internally stored data). The pointer to this copy is then 

> cached locally in the interface. It is the pointer to this locally 
> cached copy that is returned to the user. The locally cached arrays are 
> deleted when certain problem data are modified and only recreated when a 

> new pointer is requested. In particular, when any column bound is 
> changed, the locally cached copies of both the upper and lower bound 
> arrays are deleted. The common unit test requests a pointer to the 
> bounds arrays, then modifies the problem and expects that pointer to 
> remain valid. I'm not sure this is reasonable either. Pointers should 
> probably only be required to remain valid while the problem data remains 

> unchanged. I'd be curious to hear other opinions on this as well.

It is reasonable to require the user to suppose that a pointer to an 
internal array could be modified by its owning program during a subsequent
call.  For the unit test, the bounds arrays returned in the subsequent 
call should be identical to the ones obtained previously.

Best,
Alan

> 
> Cheers,
> 
> Ted
> -- 
> Dr. Ted Ralphs
> Assistant Professor
> Industrial and Systems Engineering
> Lehigh University
> (610)758-4784
> tkralphs at lehigh.edu
> www.lehigh.edu/~tkr2
> _______________________________________________
> Coin-discuss mailing list
> Coin-discuss at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/coin-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/coin-discuss/attachments/20050405/ccbd2248/attachment.html>