search

coin-or / Cgl

Cut Generator Library
Other
24 stars 14 forks source link

CglZeroHalf test fails on i386 #40

Closed svigerske closed 5 years ago

svigerske commented 5 years ago

Issue created by migration from Trac.

Original creator: @mlubin

Original creation time: 2013-11-03 15:08:07

Assignee: somebody

Cgl-0.58-2 fails to run make test on linux 32-bit x86 systems:

*****************************************
Testing CglZeroHalf with OsiClpSolverInterface

Coin0008I LSEU read with 0 errors
Coin0506I Presolve 28 (0) rows, 88 (-1) columns and 308 (-1) elements
Clp0006I 0  Obj 0 Primal inf 16.856713 (10)
Clp0006I 32  Obj 834.68235
Clp0000I Optimal - objective value 834.68235
Coin0511I After Postsolve, objective 834.68235, infeasibilities - dual 0 (0), primal 0 (0)
Clp0032I Optimal objective 834.6823529 - 32 iterations time 0.002, Presolve -0.00
Clp0006I 0  Obj 834.68235 Primal inf 0.013463473 (2)
Clp0006I 2  Obj 834.68235
Clp0000I Optimal - objective value 834.68235
Zero cuts 2
lt-unitTest: CglZeroHalfTest.cpp:89: void CglZeroHalfUnitTest(const OsiSolverInterface *, const std::string): Assertion `lpRelaxBefore < lpRelaxAfter' failed.
$ uname -a
Linux debian 3.10-3-686-pae #1 SMP Debian 3.10.11-1 (2013-09-10) i686 GNU/Linux
$ g++ --version
g++ (Debian 4.8.2-1) 4.8.2

I did some preliminary digging, and it seems like Clp returns a different optimal solution to the LP, leading to different cuts being generated which fail to improve the objective. It's hard to tell whether this means that there is anything wrong with the cut generator or if the test was just assuming a particular solution to the LP. Interestingly, when built with --enable-debug, Clp returns the same solution as on 64-bit machines and the test passes. This doesn't necessarily mean that there's a bug anywhere though; it could just be floating-point noise.

This error is blocking updating the Cgl package in Debian.

svigerske commented 5 years ago

Comment by @tkralphs created at 2013-11-10 23:13:44

This test is asserting something that cannot be guaranteed to happen. It should pass in most cases, but a failure does not necessarily indicate a bug. For now, I changed the assert to a printed warning. Later, we should implement something like what OSI has, with different severities of errors and a mechanism for indicating those that are expected, etc. I will push out to release in the next couple of days.

svigerske commented 5 years ago

Comment by @tkralphs created at 2013-11-10 23:13:44

Resolution: fixed

svigerske commented 5 years ago

Comment by @mlubin created at 2013-11-11 01:42:10

Ideally the unit test should test more specific features. For example, it could generate cuts for a hard-coded solution vector instead of being dependent on the solution provided by Clp at runtime.

svigerske commented 5 years ago

Comment by @tkralphs created at 2013-11-20 04:39:24

Yes, very true. Our unit testing setup is far from ideal for sure in many ways beyond this one :).