<br><font size=2 face="sans-serif">Few comments below</font>
<br><font size=2 face="sans-serif"> </font>
<br>
<br><font size=2><tt>coin-discuss-bounces@list.coin-or.org wrote on 04/05/2005
07:43:00 PM:<br>
<br>
> John J Forrest wrote:<br>
> > <br>
> > Ted,<br>
> > <br>
> > Does adding #include <cstdio> at top of CoinHelperFunctions.hpp
help?<br>
> > <br>
> > John<br>
> <br>
> Yes, that fixes it. Thanks.<br>
> <br>
> Also, the OsiSymSolverInterface unit test should work properly now.
<br>
> There was a bug in the copy constructor that is now fixed. Also, I
had <br>
> to comment out a few tests. SYMPHONY will not pass the common unit
tests <br>
> for two reasons:<br>
> <br>
> 1. We do not allow an infeasible solution to be loaded into the <br>
> interface. I think this is a reasonable policy, since it is natural
to <br>
> assume that the currently loaded solution is feasible to the currently
<br>
> loaded problem. SYMPHONY has no mechanism for storing an infeasible
<br>
> solution. This unit test requires this. I'm not sure this is reasonable,
<br>
> but I'd be curious to hear other opinions.<br>
</tt></font>
<br><font size=2><tt>If the user can modify the loaded solution, then it
is reasonable to assume</tt></font>
<br><font size=2><tt>that it could be infeasible.</tt></font>
<br>
<br><font size=2><tt>> <br>
> 2. Pointers to rim vectors returned by methods such as getColLower()
<br>
> become invalid if the problem is modified. This is because SYMPHONY
<br>
> itself returns a copy of requested rim vectors to the interface (not
a <br>
> pointer to the internally stored data). The pointer to this copy is
then <br>
> cached locally in the interface. It is the pointer to this locally
<br>
> cached copy that is returned to the user. The locally cached arrays
are <br>
> deleted when certain problem data are modified and only recreated
when a <br>
> new pointer is requested. In particular, when any column bound is
<br>
> changed, the locally cached copies of both the upper and lower bound
<br>
> arrays are deleted. The common unit test requests a pointer to the
<br>
> bounds arrays, then modifies the problem and expects that pointer
to <br>
> remain valid. I'm not sure this is reasonable either. Pointers should
<br>
> probably only be required to remain valid while the problem data remains
<br>
> unchanged. I'd be curious to hear other opinions on this as well.<br>
</tt></font>
<br><font size=2><tt>It is reasonable to require the user to suppose that
a pointer to an </tt></font>
<br><font size=2><tt>internal array could be modified by its owning program
during a subsequent</tt></font>
<br><font size=2><tt>call. For the unit test, the bounds arrays returned
in the subsequent </tt></font>
<br><font size=2><tt>call should be identical to the ones obtained previously.</tt></font>
<br>
<br><font size=2><tt>Best,</tt></font>
<br><font size=2><tt>Alan</tt></font>
<br>
<br><font size=2><tt>> <br>
> Cheers,<br>
> <br>
> Ted<br>
> -- <br>
> Dr. Ted Ralphs<br>
> Assistant Professor<br>
> Industrial and Systems Engineering<br>
> Lehigh University<br>
> (610)758-4784<br>
> tkralphs@lehigh.edu<br>
> www.lehigh.edu/~tkr2<br>
> _______________________________________________<br>
> Coin-discuss mailing list<br>
> Coin-discuss@list.coin-or.org<br>
> http://list.coin-or.org/mailman/listinfo/coin-discuss<br>
</tt></font>