[Coin-discuss] unitTest & column solution before solve

[Laszlo Ladanyi]

I don't mind either way.

I have a different problem, though. In the testing of the solverinterfaces
there's this piece of code:

    // Test that objective value is correct
    double correctObjValue = CoinPackedVector(nc,objCoef).dotProduct(cs);
    double siObjValue = exmip1Si->getObjValue();
    if( !eq(correctObjValue,siObjValue) )
      failureMessage(solverName,"getObjValue before solve");

Now this is a good test if and only if we define that the objective value is
the value of the primal solution. For the volume algorithm the objective value
is the value of the dual solution. And it's so serious that without using the
dual solution for objval the MaxCut and Mkc examples can break down (deliver
incorrect results). So if I want the OsiVolSolverInterface to behave as it
should then it fails this test in unitTest.

What could be done to fix this? Any ideas?

--Laci

On Thu, 24 Apr 2003, Lou Hafer wrote:

> Folks,
> 
> 	I'm working my way through the software rot in OsiDylpSolverInterface
> and have been poking at the parts of the unitTest that check for behaviour
> prior to calling a solver. I'd like to propose a change to the test for
> "getColSolution before solve", aka "make sure the column solution is
> something reasonable" (line 1797 in OsiSolverInterfaceTest.cpp).
> 
> 	Without really looking at the test, I got to asking myself `what is
> reasonable', and came up with this: The solution should provide a worst-case
> bound on the objective value. A crude way to do this is to set each primal
> variable to the `wrong' bound. For minimisation, that'd be the upper bound
> when the objective coefficient is positive, the lower bound when negative.
> In either direction, infinity is a possibility.  Unlikely to be feasible, and
> wildly pessimistic, but dead easy to construct, well-specified, and
> mathematically valid.
> 
> 	So I did this, and it failed the test. Turns out the test has the
> additional caveat that if there's at least one finite bound, then the value
> in the initial solution should be finite. This seems sort of arbitrary.
> 
> 	I'd like to propose that we remove the `prefer finite' check in the
> unit test. 
> 
> 	Further in this same direction, is there any interest in trying to
> add some principles of behaviour to the documentation for OsiSolverInterface?
> 
> 						Lou
> 
> _______________________________________________
> Coin-discuss mailing list
> Coin-discuss at www-124.ibm.com
> http://www-124.ibm.com/developerworks/oss/mailman/listinfo/coin-discuss
>