Giter Club home page Giter Club logo

cgl's Introduction

coin-or

Repository for organization-wide discussions and other organization documents.

cgl's People

Contributors

bjarnimax avatar h-g-s avatar h-i-gassmann avatar jhmgoossens avatar jjhforrest avatar johnjforrest avatar jpfasano avatar jpgoncal1 avatar louhafer avatar mjsaltzman avatar pobonomo avatar rlougee avatar samuelsbrito avatar svigerske avatar tkralphs avatar to-st avatar tosttost avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

cgl's Issues

Mingling inequalities

Issue created by migration from Trac.

Original creator: nowozin

Original creation time: 2009-01-07 15:40:09

Assignee: somebody

Atamtürk and Günlük describe an extension to mixed integer rounding inequalities for general mixed integer linear programming which incorporates variable bound information. In the conclusion to this techreport they claim it is simple to implement using only the primitives used for standard MIR separation: http://www.ieor.berkeley.edu/~atamturk/pubs/mingle.pdf

I am not familiar with the Cgl MIR implementations and maybe this has been considered before, but could a COIN-OR expert comment whether it makes sense to implement the inequalities described?

logging code always enabled in CglKnapsackCover

Issue created by migration from Trac.

Original creator: juliensf

Original creation time: 2011-03-02 21:27:01

Assignee: somebody

CC: [email protected]

The KnapsackCover cut generator has some logging code that is always enabled,
in particular it always prints the number of variables that have been fixed.

The problem is that the logging code in the function CglKnapsackCover::createCliques.
The variable logLevel is hardcoded to be 1 (CglKnapsackCover.cpp:3819). This means that
the conditional at CglKnapsackCover.cpp:3979 is always true. (And that many of those just above
it will always be false.) More importantly, it means that this cut generator doesn't respect
the usual COIN mechanisms for controlling logging output -- the fact that stdout is being
polluted by these messages is breaking our application.

(I note that this code was disabled, ie. #if 0 etc ... #endif, in previous revisisions, so maybe it
isn't necessary at all?)

Memory leak in CglFlowCover.cpp

Issue created by migration from Trac.

Original creator: @rlougee

Original creation time: 2008-06-23 17:12:18

Assignee: @rlougee

Version: release 0.5.1

Stefan Vigerske reports there's a new memory leak in CglFlowCover.cpp around lines 472, 473, 474, 475, 578, 579, 580. There is a return without the usual delete's before it freeing up the memory.

cut generators use wrong value for "infinity"

As noted in #36 and observed in #33, CglTwomir created invalid cuts when used with OsiCpx because it used a wrong value to check for absent sides of a row.
There are plenty of occurrences of (COIN_)DBL_MAX in the cut generators. Many of these should be changed to use the OSI's getInfinity().

Trac wiki wish list

The following wish list was found in the Trac wiki:

  • Have a standard interface to all cut generators <wisher: Francois Margot, June, 2006>
  • Interface needs to re-thought. Instead of the solver interface, pass in (1) what the instance is, and (2) what the solution is. Please separate those two things. If the cut needs more information, make that an optional parameter. <wisher: Jeff Linderoth, July 18, 2006>
  • All cut generators use the same value for infinity <wisher: Cindy Phillips, July 18, 2006>
  • A design for interrogating the problem once up front (e.g., building implication tables), caching the information for use later on. <wisher: Robin Lougee and many others, July 18, 2006>
  • Numerical stability of all cut generators <wisher: Francois Margot, July 19, 2006>
    • Francois -- which cuts have you experienced issues with? Robin
  • Make CGL independent of OSI. See cgl list Nov 13, 2006 post from Matt Galati.

I'm not migrating this to the new README/wiki, as wishes should go to the issue tracking, so I put it into this issue here.

Implement cliques in CglProbing

Issue created by migration from Trac.

Original creator: @LouHafer

Original creation time: 2011-02-19 00:43:14

Assignee: @LouHafer

Turns out that the clique code in CglProbing has been unused since April 2008 and never really worked. As part of the ongoing rewrite of CglProbing ([branches/CglWorking101215/src/CglProbing])) I've just lopped out all code associated with cliques, snapshots, and mode 0 (these are all intertwined). When someone comes back to get this working, the place to start is d7c1744662, the last revision that still had all the code.

Some issues on Windows [Cgl-0.59.10]

Issue created by migration from Trac.

Original creator: niuys

Original creation time: 2017-07-25 23:31:56

Assignee: somebody

Version:

Keywords: Crashed, VS 2017, Cgl

There are some issues I've encountered, fixed or still unfixed during my test with VS 2017.
Here are some issues:

  1. Some header files are not included in unitTest.cpp
    The following two files CglRedSplit2.hpp and CglZeroHalf.hpp can not be located. This can be fixed by adding in including path of the project CglUnitTest: ......\src\CglRedSplit2 and ......\src\CglZeroHalf

  2. "CglLandPUnitTest" crashed
    It is crashed at line 144 in CglLandPTest.cpp

test.generateCuts(*siP,cuts);

Debug of the issue gives the following call stack:

 	CglUnitTest.exeCoinIndexedVector::clear() line 40	C++
 	CglUnitTest.exeOsiClpSolverInterface::getBInvARow(int row, double * z, double * slack) line 6981	C++
 	CglUnitTest.exe!LAP::CglLandPSimplex::pullTableauRow(LAP::TabRow & row) line 3131	C++
 	CglUnitTest.exe!LAP::CglLandPSimplex::optimize(int row, OsiRowCut & cut, const CglLandP::CachedData & cached, const CglLandP::Parameters & params) line 674	C++
>	CglUnitTest.exeCglLandP::generateCuts(const OsiSolverInterface & si, OsiCuts & cs, const CglTreeInfo info) line 622	C++
 	CglUnitTest.exeCglLandPUnitTest(OsiSolverInterface * si, const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & mpsDir) line 145	C++
 	CglUnitTest.exe!main(int argc, const char * * argv) line 240	C++

But it works fine on Linux or with MinGW.

  1. CglZeroHalfUnitTest crashed
    It is also crashed when calling generateCuts at line 57 in CglZeroHalfTest.cpp
    cg.generateCuts(*siP,cuts);

Here is the debug call stack:

>	CglUnitTest.exe!std::_Debug_heap<cgl_node * __ptr64 * __ptr64,bool (__cdecl*)(cgl_node * __ptr64,cgl_node * __ptr64)>(cgl_node * * _First, cgl_node * * _Last, bool(*)(cgl_node *, cgl_node *) & _Pred) line 2096	C++
 	CglUnitTest.exe!std::pop_heap<std::_Vector_iterator<std::_Vector_val<std::_Simple_types<cgl_node * __ptr64> > >,bool (__cdecl*)(cgl_node * __ptr64,cgl_node * __ptr64)>(std::_Vector_iterator<std::_Vector_val<std::_Simple_types<cgl_node *> > > _First, std::_Vector_iterator<std::_Vector_val<std::_Simple_types<cgl_node *> > > _Last, bool(*)(cgl_node *, cgl_node *) _Pred) line 2226	C++
 	CglUnitTest.exe!cglShortestPath(auxiliary_graph * graph, int source, int maximumLength) line 544	C++
 	CglUnitTest.exe!get_shortest_odd_cycle_list(int j, separation_graph * s_graph, auxiliary_graph * a_graph) line 1238	C++
 	CglUnitTest.exeCgl012Cut::basic_separation() line 2233	C++
 	CglUnitTest.exeCgl012Cut::sep_012_cut(int mr, int mc, int mnz, int * mtbeg, int * mtcnt, int * mtind, int * mtval, int * vlb, int * vub, int * mrhs, char * msense, const double * xstar, bool aggressive, int * cnum, int * cnzcnt, int * * cbeg, int * * ccnt, int * * cind, int * * cval, int * * crhs, char * * csense) line 3630	C++
 	CglUnitTest.exeCglZeroHalf::generateCuts(const OsiSolverInterface & si, OsiCuts & cs, const CglTreeInfo info) line 57	C++
 	CglUnitTest.exeCglZeroHalfUnitTest(const OsiSolverInterface * baseSiP, const std::basic_string<char,std::char_traits<char>,std::allocator<char> > mpsDir) line 61	C++
 	CglUnitTest.exe!main(int argc, const char * * argv) line 305	C++

It works also on Linux and MinGW.

Concerning on the last two issues, I still have no idea why it crashed on Windows with VS 2017. I would appreciate any suggestion. Thanks in advance!

FreeBSD compile issue [stable-0.60]

On freeBSD, when using clang compiler, NULL is a typedef to nullptr so you can't use reinterpret_cast<T*>(NULL) but static_cast instead.

  1. The null pointer value of any pointer type can be converted to any other pointer type, resulting in the null pointer value of that type. Note that the null pointer constant nullptr or any other value of type std::nullptr_t cannot be converted to a pointer with reinterpret_cast: implicit conversion or static_cast should be used for this purpose.

ref: https://en.cppreference.com/w/cpp/language/reinterpret_cast

#define NULL 0
//since C++11
#define NULL nullptr

ref https://en.cppreference.com/w/cpp/types/NULL

related issue:
coin-or/Clp#93
coin-or/Cbc#319

note: You can find a patch on my fork: Mizux@f2a55f5

CglKnapsackCover::exactSolveKnapsack returns suboptimal solutions

CglKnapsackCover::exactSolveKnapsack sometimes returns suboptimal solutions. Example:

int main()
{
    const int n = 6;
    const double c = 7.0;
    const double pp[] = { 10.0, 5.0, 2, 2, 1.4, 1.1 };
    const double ww[] = { 2.0,  2.0, 2, 2, 1.5, 1.4 };

    //verify that items are sorted
    for(int i = 1; i < n; ++i)
    {
        assert(pp[i] / ww[i] <= pp[i - 1] / ww[i - 1]);
    }

    double z = 42;
    int* x = new int[n];
    exactSolveKnapsack(n, c, pp, ww, z, x);
    printf("z=%f\n", z);
    assert(fabs(z - 17.5) < 1e-3);
    delete[] x;
}

In fact Matthew Galati beat me by 6 years: https://list.coin-or.org/pipermail/cgl/2013-July/000156.html
See his post for details.

I verified that the profits are in fact fractional - simply put a "printf" into the function...
Based on the comments inside CglKnapsackCover::findExactMostViolatedMinCover it looks like this can lead to weaker (as Matthew suspected) or missed cuts (if the knapsack solution is suboptimal, "oofv = (sum (1-xstar_j))- max sum (1-xstar)y_j" gets larger and the test "oofv < 1" might fail).

By the way: there some typos in CglKnapsackCover.cpp: "inequalty", "appraoch"

gomory cuts mem leak if bad factorization

Issue created by migration from Trac.

Original creator: @mgalati13

Original creation time: 2009-09-09 20:00:51

Assignee: somebody

CC: @mgalati13

This memory leaks if a bad factorization occurs because it returns without clean-up at L312.

{{
int * rowIsBasic = new int[numberRows];
int * columnIsBasic = new int[numberColumns];
}}

error in definition of L-- in CglFlowCover.cpp

Issue created by migration from Trac.

Original creator: @rlougee

Original creation time: 2008-02-13 16:59:36

Assignee: @rlougee

In CglFlowCover.cpp, the test on line 776 should be removed and the line on 777 should be uncommented.

776 if ( y[i] >= lambda * x[i] ) { // L-
777 // if ( up[i] > lambda) { // L-

For miplib problem egout.mps with the lifting enabled, the test on line 777 leads to a variable at zero in the set L- being treated as in the set L--...producing a bad cut which chops off the optimal solution.

MSVSv8 compiler warnings

Issue created by migration from Trac.

Original creator: @mgalati13

Original creation time: 2007-02-07 14:46:37

Assignee: somebody

Version: release 0.5.1

CC: @mgalati13

Keywords: warnings

MSVSv8 compiler warnings, coin-Cbc stable 1.1

Warning	1	warning C4996: 'strdup' was declared deprecated	c:\cygwin\home\magala\coin\coin-cbc\cgl\src\cgltwomir\cgltwomir.cpp	184	
Warning	2	warning C4996: 'strcpy' was declared deprecated	c:\cygwin\home\magala\coin\coin-cbc\cgl\src\cglmessage.cpp	33	
Warning	3	warning C4996: 'std::_Transform' was declared deprecated	c:\program files\microsoft visual studio 8\vc\include\algorithm	685	
Warning	4	warning C4996: 'std::_Copy_opt' was declared deprecated	c:\program files\microsoft visual studio 8\vc\include\xutility	2282	

CglPreProcess does not use message handler for output

Issue created by migration from Trac.

Original creator: @svigerske

Original creation time: 2007-01-19 18:36:59

Assignee: fmargot

Version: release 0.5.1

Hi,

at line 1286 in CglPreProcess.cpp it is written:
{{{
if (handler_->logLevel()>1)
printf("%d elements changed\n",numberChanges);
}}}
I think, the message handler should be used for this output, or the output can be eleminated.

I use release 0.5.1, but it's also in the current trunk version (lines 1273, 1297).

Stefan

CGL probing cut code does not work with all LP solvers

Issue created by migration from Trac.

Original creator: [email protected]

Original creation time: 2006-09-07 22:00:06

Assignee: somebody

Version:

Keywords: Probing cuts

Probing cuts make the following call

si.getDblParam(OsiDualObjectiveLimit,cutoff);

four times in CglProbing.cpp (lines 1412, 1457, 2474, and 4032 in the tarball from 9/6/06).
Some LP solvers, in particular soplex, do not support this parameter. The OsiSpxSolverInterface
returns a value of "false" to indicate the problem. Since the probing cut code does not look at
the return value, the variable cutoff can contain garbage.

The simple fix for the simple problem is to replace the above line of code (in all instances) with:

bool cutoff_OK = si.getDblParam(OsiDualObjectiveLimit,cutoff);
if (!cutoff_OK) // cut off isn't set or isn't valid
cutoff = si.getInfinity();

invalid write in Cgl012Cut::get_cut

With the current Cbc/master and stable/2.10, I get valgrind complains on instance
012.mps.txt and crashes on Windows.

Welcome to the CBC MILP Solver 
Version: Trunk (unstable) 
Build Date: Apr  8 2019 
Revision Number: 2526 

command line - ./bin/cbc 012.mps (default strategy 1)
At line 1 NAME          BLANK     FREE
At line 2 ROWS
At line 9 COLUMNS
At line 113 RHS
At line 116 BOUNDS
At line 169 ENDATA
Problem BLANK has 5 rows, 53 columns and 204 elements
Coin0008I BLANK read with 0 errors
Continuous objective value is -2069.5 - 0.72 seconds
Cgl0003I 0 fixed, 1 tightened bounds, 0 strengthened rows, 0 substitutions
Cgl0004I processed model has 3 rows, 51 columns (50 integer (50 of which binary)) and 151 elements
Cbc0038I Initial state - 3 integers unsatisfied sum - 0.478844
Cbc0038I Pass   1: suminf.    0.01042 (1) obj. -2059.22 iterations 6
Cbc0038I Pass   2: suminf.    0.24601 (2) obj. -2018.73 iterations 3
Cbc0038I Pass   3: suminf.    0.00000 (0) obj. -2011 iterations 2
Cbc0038I Solution found of -2011
Cbc0038I Relaxing continuous gives -2011
Cbc0038I Before mini branch and bound, 44 integers at bound fixed and 0 continuous
Cbc0038I Full problem 3 rows 51 columns, reduced to 3 rows 7 columns
Cbc0038I Mini branch and bound did not improve solution (2.34 seconds)
Cbc0038I Round again with cutoff of -2016.85
Cbc0038I Reduced cost fixing fixed 12 variables on major pass 2
Cbc0038I Pass   4: suminf.    0.01042 (1) obj. -2059.22 iterations 0
Cbc0038I Pass   5: suminf.    0.24601 (2) obj. -2018.73 iterations 3
Cbc0038I Pass   6: suminf.    0.07312 (1) obj. -2016.85 iterations 3
Cbc0038I Pass   7: suminf.    0.14063 (1) obj. -2022.25 iterations 1
Cbc0038I Pass   8: suminf.    1.06929 (4) obj. -2016.85 iterations 9
Cbc0038I Pass   9: suminf.    0.73594 (3) obj. -2016.85 iterations 5
Cbc0038I Pass  10: suminf.    0.13542 (1) obj. -2032.84 iterations 3
Cbc0038I Pass  11: suminf.    0.95885 (4) obj. -2016.85 iterations 8
Cbc0038I Pass  12: suminf.    0.63241 (2) obj. -2021.33 iterations 5
Cbc0038I Pass  13: suminf.    0.21272 (2) obj. -2016.85 iterations 2
Cbc0038I Pass  14: suminf.    0.52528 (2) obj. -2029.02 iterations 4
Cbc0038I Pass  15: suminf.    0.33158 (1) obj. -2028.12 iterations 3
Cbc0038I Pass  16: suminf.    0.40345 (2) obj. -2016.85 iterations 3
Cbc0038I Pass  17: suminf.    0.69434 (2) obj. -2043.89 iterations 2
Cbc0038I Pass  18: suminf.    1.31896 (4) obj. -2016.85 iterations 4
Cbc0038I Pass  19: suminf.    0.96725 (3) obj. -2016.85 iterations 2
Cbc0038I Pass  20: suminf.    0.78897 (3) obj. -2016.85 iterations 1
Cbc0038I Pass  21: suminf.    0.48931 (3) obj. -2016.85 iterations 6
Cbc0038I Pass  22: suminf.    0.37951 (3) obj. -2016.85 iterations 2
Cbc0038I Pass  23: suminf.    1.30062 (3) obj. -2016.85 iterations 4
Cbc0038I Pass  24: suminf.    1.30062 (3) obj. -2016.85 iterations 0
Cbc0038I Pass  25: suminf.    0.50436 (3) obj. -2016.85 iterations 2
Cbc0038I Pass  26: suminf.    0.45916 (2) obj. -2019.2 iterations 2
Cbc0038I Pass  27: suminf.    0.37071 (3) obj. -2016.85 iterations 4
Cbc0038I Pass  28: suminf.    0.29376 (2) obj. -2020.7 iterations 1
Cbc0038I Pass  29: suminf.    0.82477 (3) obj. -2016.85 iterations 6
Cbc0038I Pass  30: suminf.    0.78631 (2) obj. -2016.85 iterations 2
Cbc0038I Pass  31: suminf.    0.97732 (3) obj. -2036.12 iterations 3
Cbc0038I Pass  32: suminf.    0.70961 (3) obj. -2026.83 iterations 2
Cbc0038I Pass  33: suminf.    1.06690 (3) obj. -2016.85 iterations 1
Cbc0038I No solution found this major pass
Cbc0038I Before mini branch and bound, 32 integers at bound fixed and 0 continuous
Cbc0038I Full problem 3 rows 51 columns, reduced to 3 rows 19 columns
Cbc0038I Mini branch and bound improved solution from -2011 to -2031 (3.31 seconds)
Cbc0038I Round again with cutoff of -2038.7
Cbc0038I Reduced cost fixing fixed 22 variables on major pass 3
Cbc0038I Pass  33: suminf.    0.01099 (1) obj. -2059.23 iterations 2
Cbc0038I Pass  34: suminf.    0.39599 (2) obj. -2038.7 iterations 4
Cbc0038I Pass  35: suminf.    0.24624 (1) obj. -2038.7 iterations 2
Cbc0038I Pass  36: suminf.    0.63093 (2) obj. -2048.65 iterations 2
Cbc0038I Pass  37: suminf.    0.41258 (2) obj. -2047.17 iterations 1
Cbc0038I Pass  38: suminf.    0.77449 (3) obj. -2038.7 iterations 2
Cbc0038I Pass  39: suminf.    0.99161 (4) obj. -2038.7 iterations 6
Cbc0038I Pass  40: suminf.    0.93114 (4) obj. -2038.7 iterations 2
Cbc0038I Pass  41: suminf.    0.52202 (3) obj. -2038.7 iterations 3
Cbc0038I Pass  42: suminf.    0.24624 (1) obj. -2038.7 iterations 2
Cbc0038I Pass  43: suminf.    0.27604 (1) obj. -2041.08 iterations 1
Cbc0038I Pass  44: suminf.    1.07639 (4) obj. -2038.7 iterations 7
Cbc0038I Pass  45: suminf.    0.77789 (3) obj. -2038.7 iterations 2
Cbc0038I Pass  46: suminf.    1.09304 (3) obj. -2058.93 iterations 4
Cbc0038I Pass  47: suminf.    0.96287 (3) obj. -2038.7 iterations 2
Cbc0038I Pass  48: suminf.    0.38374 (1) obj. -2038.7 iterations 3
Cbc0038I Pass  49: suminf.    0.47396 (1) obj. -2051.7 iterations 2
Cbc0038I Pass  50: suminf.    0.44565 (1) obj. -2049.75 iterations 1
Cbc0038I Pass  51: suminf.    1.12687 (4) obj. -2038.7 iterations 4
Cbc0038I Pass  52: suminf.    0.78071 (4) obj. -2038.7 iterations 3
Cbc0038I Pass  53: suminf.    0.67418 (3) obj. -2038.7 iterations 3
Cbc0038I Pass  54: suminf.    0.50799 (2) obj. -2038.7 iterations 2
Cbc0038I Pass  55: suminf.    1.10780 (3) obj. -2046.67 iterations 4
Cbc0038I Pass  56: suminf.    0.50799 (2) obj. -2038.7 iterations 2
Cbc0038I Pass  57: suminf.    1.08186 (3) obj. -2038.7 iterations 5
Cbc0038I Pass  58: suminf.    0.53006 (3) obj. -2038.7 iterations 3
Cbc0038I Pass  59: suminf.    0.48903 (2) obj. -2049.85 iterations 4
Cbc0038I Pass  60: suminf.    0.48903 (2) obj. -2049.85 iterations 0
Cbc0038I Pass  61: suminf.    0.58337 (2) obj. -2038.7 iterations 1
Cbc0038I Pass  62: suminf.    0.97818 (4) obj. -2038.7 iterations 6
Cbc0038I No solution found this major pass
Cbc0038I Before mini branch and bound, 35 integers at bound fixed and 0 continuous
Cbc0038I Full problem 3 rows 51 columns, reduced to 3 rows 16 columns
Cbc0038I Mini branch and bound did not improve solution (3.73 seconds)
Cbc0038I After 3.74 seconds - Feasibility pump exiting with objective of -2031 - took 2.16 seconds
Cbc0012I Integer solution of -2031 found by feasibility pump after 0 iterations and 0 nodes (3.75 seconds)
Cbc0038I Full problem 3 rows 51 columns, reduced to 3 rows 6 columns
==5790== Invalid write of size 4
==5790==    at 0x3F473A: Cgl012Cut::get_cut(cycle*) (Cgl012cut.cpp:1690)
==5790==    by 0x3F61E0: Cgl012Cut::basic_separation() (Cgl012cut.cpp:2239)
==5790==    by 0x3F8341: Cgl012Cut::sep_012_cut(int, int, int, int*, int*, int*, int*, int*, int*, int*, char*, double const*, bool, int*, int*, int**, int**, int**, int**, int**, char**) (Cgl012cut.cpp:3632)
==5790==    by 0x3D1107: CglZeroHalf::generateCuts(OsiSolverInterface const&, OsiCuts&, CglTreeInfo) (CglZeroHalf.cpp:49)
==5790==    by 0x210B9F: CbcCutGenerator::generateCuts(OsiCuts&, int, OsiSolverInterface*, CbcNode*) (CbcCutGenerator.cpp:312)
==5790==    by 0x28CAD1: CbcModel::serialCuts(OsiCuts&, CbcNode*, OsiCuts&, int) (CbcModel.cpp:9825)
==5790==    by 0x287A46: CbcModel::solveWithCuts(OsiCuts&, int, CbcNode*) (CbcModel.cpp:8450)
==5790==    by 0x271D67: CbcModel::branchAndBound(int) (CbcModel.cpp:3098)
==5790==    by 0x159A8C: CbcMain1(int, char const**, CbcModel&, int (*)(CbcModel*, int), CbcSolverUsefulData&) (CbcSolver.cpp:7307)
==5790==    by 0x135DA9: main (CoinSolve.cpp:354)
==5790==  Address 0xf64f0b4 is 0 bytes after a block of size 4 alloc'd
==5790==    at 0x4839B65: calloc (vg_replace_malloc.c:752)
==5790==    by 0x3F469D: Cgl012Cut::get_cut(cycle*) (Cgl012cut.cpp:1674)
==5790==    by 0x3F61E0: Cgl012Cut::basic_separation() (Cgl012cut.cpp:2239)
==5790==    by 0x3F8341: Cgl012Cut::sep_012_cut(int, int, int, int*, int*, int*, int*, int*, int*, int*, char*, double const*, bool, int*, int*, int**, int**, int**, int**, int**, char**) (Cgl012cut.cpp:3632)
==5790==    by 0x3D1107: CglZeroHalf::generateCuts(OsiSolverInterface const&, OsiCuts&, CglTreeInfo) (CglZeroHalf.cpp:49)
==5790==    by 0x210B9F: CbcCutGenerator::generateCuts(OsiCuts&, int, OsiSolverInterface*, CbcNode*) (CbcCutGenerator.cpp:312)
==5790==    by 0x28CAD1: CbcModel::serialCuts(OsiCuts&, CbcNode*, OsiCuts&, int) (CbcModel.cpp:9825)
==5790==    by 0x287A46: CbcModel::solveWithCuts(OsiCuts&, int, CbcNode*) (CbcModel.cpp:8450)
==5790==    by 0x271D67: CbcModel::branchAndBound(int) (CbcModel.cpp:3098)
==5790==    by 0x159A8C: CbcMain1(int, char const**, CbcModel&, int (*)(CbcModel*, int), CbcSolverUsefulData&) (CbcSolver.cpp:7307)
==5790==    by 0x135DA9: main (CoinSolve.cpp:354)
==5790== 
==5790== Invalid read of size 4
==5790==    at 0x3F3ABC: Cgl012Cut::get_ori_cut_coef(int, int*, int*, int*, short) (Cgl012cut.cpp:1468)
==5790==    by 0x3F477E: Cgl012Cut::get_cut(cycle*) (Cgl012cut.cpp:1693)
==5790==    by 0x3F61E0: Cgl012Cut::basic_separation() (Cgl012cut.cpp:2239)
==5790==    by 0x3F8341: Cgl012Cut::sep_012_cut(int, int, int, int*, int*, int*, int*, int*, int*, int*, char*, double const*, bool, int*, int*, int**, int**, int**, int**, int**, char**) (Cgl012cut.cpp:3632)
==5790==    by 0x3D1107: CglZeroHalf::generateCuts(OsiSolverInterface const&, OsiCuts&, CglTreeInfo) (CglZeroHalf.cpp:49)
==5790==    by 0x210B9F: CbcCutGenerator::generateCuts(OsiCuts&, int, OsiSolverInterface*, CbcNode*) (CbcCutGenerator.cpp:312)
==5790==    by 0x28CAD1: CbcModel::serialCuts(OsiCuts&, CbcNode*, OsiCuts&, int) (CbcModel.cpp:9825)
==5790==    by 0x287A46: CbcModel::solveWithCuts(OsiCuts&, int, CbcNode*) (CbcModel.cpp:8450)
==5790==    by 0x271D67: CbcModel::branchAndBound(int) (CbcModel.cpp:3098)
==5790==    by 0x159A8C: CbcMain1(int, char const**, CbcModel&, int (*)(CbcModel*, int), CbcSolverUsefulData&) (CbcSolver.cpp:7307)
==5790==    by 0x135DA9: main (CoinSolve.cpp:354)
==5790==  Address 0xf64f0b4 is 0 bytes after a block of size 4 alloc'd
==5790==    at 0x4839B65: calloc (vg_replace_malloc.c:752)
==5790==    by 0x3F469D: Cgl012Cut::get_cut(cycle*) (Cgl012cut.cpp:1674)
==5790==    by 0x3F61E0: Cgl012Cut::basic_separation() (Cgl012cut.cpp:2239)
==5790==    by 0x3F8341: Cgl012Cut::sep_012_cut(int, int, int, int*, int*, int*, int*, int*, int*, int*, char*, double const*, bool, int*, int*, int**, int**, int**, int**, int**, char**) (Cgl012cut.cpp:3632)
==5790==    by 0x3D1107: CglZeroHalf::generateCuts(OsiSolverInterface const&, OsiCuts&, CglTreeInfo) (CglZeroHalf.cpp:49)
==5790==    by 0x210B9F: CbcCutGenerator::generateCuts(OsiCuts&, int, OsiSolverInterface*, CbcNode*) (CbcCutGenerator.cpp:312)
==5790==    by 0x28CAD1: CbcModel::serialCuts(OsiCuts&, CbcNode*, OsiCuts&, int) (CbcModel.cpp:9825)
==5790==    by 0x287A46: CbcModel::solveWithCuts(OsiCuts&, int, CbcNode*) (CbcModel.cpp:8450)
==5790==    by 0x271D67: CbcModel::branchAndBound(int) (CbcModel.cpp:3098)
==5790==    by 0x159A8C: CbcMain1(int, char const**, CbcModel&, int (*)(CbcModel*, int), CbcSolverUsefulData&) (CbcSolver.cpp:7307)
==5790==    by 0x135DA9: main (CoinSolve.cpp:354)
==5790== 
==5790== Invalid read of size 4
==5790==    at 0x3F3B50: Cgl012Cut::get_ori_cut_coef(int, int*, int*, int*, short) (Cgl012cut.cpp:1479)
==5790==    by 0x3F477E: Cgl012Cut::get_cut(cycle*) (Cgl012cut.cpp:1693)
==5790==    by 0x3F61E0: Cgl012Cut::basic_separation() (Cgl012cut.cpp:2239)
==5790==    by 0x3F8341: Cgl012Cut::sep_012_cut(int, int, int, int*, int*, int*, int*, int*, int*, int*, char*, double const*, bool, int*, int*, int**, int**, int**, int**, int**, char**) (Cgl012cut.cpp:3632)
==5790==    by 0x3D1107: CglZeroHalf::generateCuts(OsiSolverInterface const&, OsiCuts&, CglTreeInfo) (CglZeroHalf.cpp:49)
==5790==    by 0x210B9F: CbcCutGenerator::generateCuts(OsiCuts&, int, OsiSolverInterface*, CbcNode*) (CbcCutGenerator.cpp:312)
==5790==    by 0x28CAD1: CbcModel::serialCuts(OsiCuts&, CbcNode*, OsiCuts&, int) (CbcModel.cpp:9825)
==5790==    by 0x287A46: CbcModel::solveWithCuts(OsiCuts&, int, CbcNode*) (CbcModel.cpp:8450)
==5790==    by 0x271D67: CbcModel::branchAndBound(int) (CbcModel.cpp:3098)
==5790==    by 0x159A8C: CbcMain1(int, char const**, CbcModel&, int (*)(CbcModel*, int), CbcSolverUsefulData&) (CbcSolver.cpp:7307)
==5790==    by 0x135DA9: main (CoinSolve.cpp:354)
==5790==  Address 0xf64f0b4 is 0 bytes after a block of size 4 alloc'd
==5790==    at 0x4839B65: calloc (vg_replace_malloc.c:752)
==5790==    by 0x3F469D: Cgl012Cut::get_cut(cycle*) (Cgl012cut.cpp:1674)
==5790==    by 0x3F61E0: Cgl012Cut::basic_separation() (Cgl012cut.cpp:2239)
==5790==    by 0x3F8341: Cgl012Cut::sep_012_cut(int, int, int, int*, int*, int*, int*, int*, int*, int*, char*, double const*, bool, int*, int*, int**, int**, int**, int**, int**, char**) (Cgl012cut.cpp:3632)
==5790==    by 0x3D1107: CglZeroHalf::generateCuts(OsiSolverInterface const&, OsiCuts&, CglTreeInfo) (CglZeroHalf.cpp:49)
==5790==    by 0x210B9F: CbcCutGenerator::generateCuts(OsiCuts&, int, OsiSolverInterface*, CbcNode*) (CbcCutGenerator.cpp:312)
==5790==    by 0x28CAD1: CbcModel::serialCuts(OsiCuts&, CbcNode*, OsiCuts&, int) (CbcModel.cpp:9825)
==5790==    by 0x287A46: CbcModel::solveWithCuts(OsiCuts&, int, CbcNode*) (CbcModel.cpp:8450)
==5790==    by 0x271D67: CbcModel::branchAndBound(int) (CbcModel.cpp:3098)
==5790==    by 0x159A8C: CbcMain1(int, char const**, CbcModel&, int (*)(CbcModel*, int), CbcSolverUsefulData&) (CbcSolver.cpp:7307)
==5790==    by 0x135DA9: main (CoinSolve.cpp:354)
==5790== 
Cbc0031I 8 added rows had average density of 28.75
Cbc0013I At root node, 8 cuts changed objective from -2069.4962 to -2056.6301 in 13 passes
Cbc0014I Cut generator 0 (Probing) - 0 row cuts average 0.0 elements, 1 column cuts (1 active)  in 0.046 seconds - new frequency is 1
Cbc0014I Cut generator 1 (Gomory) - 26 row cuts average 31.1 elements, 0 column cuts (0 active)  in 0.084 seconds - new frequency is 1
Cbc0014I Cut generator 2 (Knapsack) - 10 row cuts average 17.4 elements, 0 column cuts (0 active)  in 0.501 seconds - new frequency is 1
Cbc0014I Cut generator 3 (Clique) - 0 row cuts average 0.0 elements, 0 column cuts (0 active)  in 0.031 seconds - new frequency is -100
Cbc0014I Cut generator 4 (MixedIntegerRounding2) - 25 row cuts average 29.2 elements, 0 column cuts (0 active)  in 0.118 seconds - new frequency is 1
Cbc0014I Cut generator 5 (FlowCover) - 1 row cuts average 13.0 elements, 0 column cuts (0 active)  in 0.059 seconds - new frequency is -100
Cbc0014I Cut generator 6 (TwoMirCuts) - 65 row cuts average 30.6 elements, 0 column cuts (0 active)  in 0.182 seconds - new frequency is 1
Cbc0014I Cut generator 7 (ZeroHalf) - 2 row cuts average 50.0 elements, 0 column cuts (0 active)  in 0.289 seconds - new frequency is -100
Cbc0010I After 0 nodes, 1 on tree, -2031 best solution, best possible -2056.6301 (5.94 seconds)
Cbc0012I Integer solution of -2038 found by DiveCoefficient after 202 iterations and 3 nodes (7.83 seconds)
Cbc0001I Search completed - best objective -2038.00002647658, took 613 iterations and 30 nodes (10.47 seconds)
Cbc0032I Strong branching done 262 times (1301 iterations), fathomed 5 nodes and fixed 8 variables
Cbc0035I Maximum depth 10, 163 variables fixed on reduced cost
Cuts at root node changed objective from -2069.5 to -2056.63
Probing was tried 68 times and created 10 cuts of which 0 were active after adding rounds of cuts (0.131 seconds)
Gomory was tried 62 times and created 48 cuts of which 0 were active after adding rounds of cuts (0.220 seconds)
Knapsack was tried 62 times and created 98 cuts of which 0 were active after adding rounds of cuts (1.918 seconds)
Clique was tried 13 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.031 seconds)
MixedIntegerRounding2 was tried 62 times and created 161 cuts of which 0 were active after adding rounds of cuts (0.435 seconds)
FlowCover was tried 13 times and created 1 cuts of which 0 were active after adding rounds of cuts (0.059 seconds)
TwoMirCuts was tried 62 times and created 287 cuts of which 0 were active after adding rounds of cuts (0.586 seconds)
ZeroHalf was tried 13 times and created 2 cuts of which 0 were active after adding rounds of cuts (0.289 seconds)

Result - Optimal solution found

Objective value:                -2038.00002648
Enumerated nodes:               30
Total iterations:               613
Time (CPU seconds):             10.57
Time (Wallclock seconds):       11.06

Total time (CPU seconds):       10.83   (Wallclock seconds):       11.33

trunk CglValidator::fillRejectionReasons dumps core, Solaris / Studio / optimised build

Issue created by migration from Trac.

Original creator: @LouHafer

Original creation time: 2007-04-02 18:08:26

Assignee: @pobonomo

Trunk CglValidator::fillRejectionReasons triggers a core dump on Solaris 10 using the Studio compilers (Sun C++ 5.8 Patch 121017-04 2006/08/02) and an optimised build. Reserving space for the vector fixes the problem:

void
CglValidator::fillRejectionReasons()
{ 
  rejections_.reserve(DummyEnd) ;
  rejections_[NoneAccepted] = "Cut was accepted";
     . . .

I suspect it's just luck that the debug build doesn't core dump. The Studio compilers seem to expect explicit reservation of space before use of an index to access the vector.

CglRedSplit unsafe mix of type 'bool' and type 'int' in operation.

Issue created by migration from Trac.

Original creator: @jpfasano

Original creation time: 2007-04-11 15:20:27

Assignee: somebody

MSVS V8 compiler reports:

coin-cbc\cgl\src\cglredsplit\cglredsplit.cpp(1134) : warning C4805: '!=' : unsafe mix of type 'bool' and type 'int' in operation

The specific line referred to is:

if(solver->optimalBasisIsAvailable() != rsData.getOptimalBasisIsAvailable()) {

extra output in CglLanP

Issue created by migration from Trac.

Original creator: fmargot

Original creation time: 2007-07-05 11:43:49

Assignee: @pobonomo

CC: [email protected]

The line (approx 565 in CglLandP.cpp)

std::cout<<"Failed to generate a cut generate a Gomory cut instead"<<std::endl;

should not be printed by default. Putting it
inside an #ifdef LandP_DEBUG would be welcome.
Both trunk and stable versions are affected.

Bug in the CglFlowVUB copy constructor

Issue created by migration from Trac.

Original creator: @rlougee

Original creation time: 2007-11-16 18:21:14

Assignee: somebody

Version: release 0.5.1

In CglFlowCover.hpp

CglFlowVUB(const CglFlowVUB& source) { 

varInd_= source.varInd_; 

upper_ = source.varInd_;  // rlh: the bug

}

The fix is:
upper_ = source.upper_;

Cgl will not build with Microsoft Visual C++ Toolkit

Issue created by migration from Trac.

Original creator: @tkralphs

Original creation time: 2006-11-29 00:08:49

Assignee: somebody

Version: 1.0

Cgl does not build properly using the autotools with the Microsoft compiler that come with the Visual C++ Toolkit 2003. It fails when it tries to build the library. I can try to reproduce the error if you want, but I don't have it handy to paste here. You may not care about fixing this, since it seems to work with the free Microsoft compiler that comes with Visual C++ Express 2005, which is a more recent compiler anyway.

CglTwomir generates invalid cuts

Issue created by migration from Trac.

Original creator: ojasparekh

Original creation time: 2010-09-20 23:31:08

Assignee: somebody

Version: release 0.5.1

In determining whether a row is bounded, the DGG_getData function uses a fixed value of DBL_MAX rather than the OsiSolverInterface object's getInfinity() value. This resulted in invalid cuts with OsiCpxSolverInterfacel. This bug may affect other Cgl generators as well.

CglKnapsackCover::deriveAKnapsack asserts when leMatrixRow has 0 element

Issue created by migration from Trac.

Original creator: San

Original creation time: 2007-02-06 02:26:41

Assignee: fmargot

Version: release 0.5.1

Code asserted when attempting to transform a matrix with 0 elements. The fix is attached to this ticket.

    if (leMatrixRow.getNumElements() > 0)
    {
        std::transform(leMatrixRow.getElements(),
		       leMatrixRow.getElements() + leMatrixRow.getNumElements(),
		       leMatrixRow.getElements(),
		       std::negate<double>());
    }

warning forcing value to bool

Issue created by migration from Trac.

Original creator: @mgalati13

Original creation time: 2008-07-15 22:35:25

Assignee: somebody

CC: @mgalati13

5>c:\cygwin\home\magala\coin\coin-decomp\cgl\src\cglflowcover\cglflowcover.cpp(992) : warning C4800: 'int' : forcing value to bool 'true' or 'false' (performance warning)

EXTRA_DIST contains examples/cgl2.cpp

Issue created by migration from Trac.

Original creator: @svigerske

Original creation time: 2007-02-04 13:07:58

Assignee: fmargot

Version: release 0.5.1

Hi,

the EXTRA_DIST variable in Makefile.am (project main directory) contains an examples/cgl2.cpp which does not exists. This makes "make dist" failing.

Stefan

CglFlowCover cut chops off optimal solution to egout

Issue created by migration from Trac.

Original creator: @rlougee

Original creation time: 2008-06-13 14:45:32

Assignee: somebody

Version: stable 0.5

John Forrest sent me an example where a CglFlowCover cut chops off the optimal solution to egout. John turned off lifting in CglFlowCover cuts in stable and trunk.

Cgl012cut.hpp should be installed to includedir

Issue created by migration from Trac.

Original creator: @mlubin

Original creation time: 2013-10-24 04:54:46

Assignee: somebody

CglZeroHalf.hpp includes Cgl012cut.hpp, but Cgl012cut.hpp is not installed to include/coin. This breaks building cbc against a system-installed cgl. This issue is easily fixed by making the required changes to includecoin_HEADERS in src/CglZeroHalf/Makefile.am.

OsiMsk upgrade requires change in Mosek detection in configure.ac

Issue created by migration from Trac.

Original creator: @LouHafer

Original creation time: 2007-12-06 16:38:58

Assignee: somebody

Version: release 0.5.1

OsiMsk has been updated. In Cgl/configure.ac, the file used to confirm Mosek presence should be changed from mosekdl.h to mosek.h:

AC_COIN_HAS_USER_LIBRARY([Mosek],[MSK],[mosek.h],[MSK_openmosek])

Currently, only Osi/trunk is updated. There will be a follow-on ticket when the OsiMsk update is moved out to stable & release.

knapsack cover cuts off optimal solution

Issue created by migration from Trac.

Original creator: @ashutoshmahajan

Original creation time: 2009-12-11 01:34:19

Assignee: somebody

Version:

One of the users of SYMPHONY provided an instance on which the KnapsackCover cuts off the optimal solution.

The LP files and the code that reproduces the problem are located here:

http://coral.ie.lehigh.edu/~asm4/tmp/knapsack/

out1.lp is the original instance. out2.lp is the instance obtained after adding CglKnapsackCover inequalities. solving out2.lp with cplex or cbc gives a solution value of 401, while out1.lp gives 397.

Affects trunk and release version 0.54.2

CglZeroHalf test fails on i386

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.

Attempt to instantiate abstract class in CglCliqueHelper.cpp

Issue created by migration from Trac.

Original creator: dan.gordon

Original creation time: 2006-06-22 01:19:36

Assignee: somebody

Version:

When I try to compile in CglClique under Mac OSX 10.4, I get the following error:

CglCliqueHelper.cpp:86: error: cannot allocate an object of abstract type 'const CoinPackedVectorBase'
/devel/COIN/Coin-CoinAll/CoinUtils/src/CoinPackedVectorBase.hpp:25: note:   because the following virtual functions are pure within 'const CoinPackedVectorBase':
/devel/COIN/Coin-CoinAll/CoinUtils/src/CoinPackedVectorBase.hpp:31: note:  virtual int CoinPackedVectorBase::getNumElements() const
...

This is obviously because CoinPackedVectorBase::GetVector(...) returns by value. Hence the error is fixed by changing lines like

const CoinPackedVectorBase& vec = mcol.getVector(sp_orig_col_ind[j]);

to

const CoinShallowPackedVector vec = mcol.getVector(sp_orig_col_ind[j]);

Problem with unbounded rows

Issue created by migration from Trac.

Original creator: jpgoncal

Original creation time: 2007-09-07 13:30:49

Assignee: somebody

Version: stable 0.5

The code breaks when it is given an unbounded row.

CglTwomir probname_; inconsistent usage, possible trivial memory leak

Issue created by migration from Trac.

Original creator: @LouHafer

Original creation time: 2007-05-31 21:59:21

Assignee: somebody

Probname_ is declared as (char *), is not consistently loaded with a value, and the destructor does not free the space. Attached files convert probname_ to std::string and clean up the usage just a little bit.

Potential error in CglTwomir

Issue created by migration from Trac.

Original creator: jwatson

Original creation time: 2009-12-11 05:43:05

Assignee: somebody

Version: release 0.5.1

I have isolated a situation in which I believe CglTwomir is returning invalid cuts. I have attached a test driver (driver.cpp), a test input file (mas74.mps, from miplib2003), and the output trace I obtain on our rather vanilla RedHat linux server.

The “catch” is that I’m using CPLEX 11.2, and the OsiCpxSolverInterface. Although this technically shouldn’t matter, I suppose (the behavior also occurs with other versions of CPLEX).

A quick summary of the unexpected behavior:

  1. The LP relaxation for mas74 solves fine – relaxation is around 10K. Validated with various other solvers.
  2. 3 two-mir cuts are found and successfully applied.
  3. Upon re-solve after cut addition, the LP relaxation is something like 21K, which is far above the integer optimal of ~11K. Obviously incorrect behavior.

Any help is greatly appreciated – I am seeing similar behavior on a handful of other test instances.

Thanks!

Jean-Paul

use of type 'bool' in operation

Issue created by migration from Trac.

Original creator: @mgalati13

Original creation time: 2008-07-15 20:51:10

Assignee: somebody

CC: @mgalati13

c:\cygwin\home\magala\coin\coin-decomp\cgl\src\cgltreeinfo.cpp(1021) : warning C4804: '>' : unsafe use of type 'bool' in operation

CglSimpleRoundingTest fails; solver-dependent coding

Issue created by migration from Trac.

Original creator: @LouHafer

Original creation time: 2007-05-31 21:44:14

Assignee: @rlougee

The test around line 101 (srRowCut2 == solRowCut) fails because it assumes an ordering for indices in the packed vector returned from the cut. Different underlying solvers will produce different orders.

This will test for mathematical equality, not structural equality; critical change is isEquivalent:

assert(srRowCut2.OsiCut::operator==(solRowCut)) ;
assert(srRowCut2.row().isEquivalent(solRowCut.row())) ;
assert(srRowCut2.lb() == solRowCut.lb()) ;
assert(srRowCut2.ub() == solRowCut.ub()) ;

Integer overflow in CglPreProcess.cpp

CglPreProcess.cpp line 7779 can overflow. As xx.i is signed, this is undefined behaviour.

How to reproduce:
Build Cbc with UBSAN and run the tests:
coinbrew build C --prefix="/build/dir" CFLAGS="-fsanitize=undefined -Wformat -Werror=format-security -Werror=array-bounds -g" CXXFLAGS="-fsanitize=undefined -Wformat -Werror=format-security -Werror=array-bounds -g" LDFLAGS="-fsanitize=undefined" --test

Note

  • type punning using unions is undefined behaviour in C++ [1], so switching to an unsigned int does not fix this
    • type punning using unions is defined in C99
    • g++ supports it as an extension [2]
    • there are other places in the codebase that do type punning using unions.

[1] http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Ru-pun
[2] https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-fstrict-aliasing

g++ compiler warnings

Issue created by migration from Trac.

Original creator: @mgalati13

Original creation time: 2007-02-08 21:40:34

Assignee: somebody

Version: stable 0.5

CC: @mgalati13

Keywords: warnings

g++ linux compiler warnings

../../../../Cgl/src/CglKnapsackCover/CglKnapsackCover.cpp: In member function `void CglKnapsackCover::liftUpDownAndUncomplementAndAdd(int, double*\
, int*, int, int, double&, CoinPackedVector&, CoinPackedVector&, CoinPackedVector&, OsiCuts&) const':
../../../../Cgl/src/CglKnapsackCover/CglKnapsackCover.cpp:2055: warning: unused variable 'firstFrac'
../../../../Cgl/src/CglPreProcess/CglPreProcess.cpp: In member function `void CglPreProcess::postProcess(OsiSolverInterface&)':
../../../../Cgl/src/CglPreProcess/CglPreProcess.cpp:1450: warning: unused variable 'solutionM2'

Conditional jump or move depends on uninitialised value

Issue created by migration from Trac.

Original creator: @tkralphs

Original creation time: 2007-04-09 03:04:09

Assignee: @rlougee

Version: stable 0.5

Valgrind output from solving blend2 with SYMPHONY trunk revision 1043

==1641== Conditional jump or move depends on uninitialised value(s)
==1641== at 0x80A868E: CglKnapsackCover::liftCoverCut(double&, int, CoinPack
edVector&, CoinPackedVector&, CoinPackedVector&) const (CglKnapsackCover.cpp:25
40)
==1641== by 0x80AA251: CglKnapsackCover::liftAndUncomplementAndAdd(double, C
oinPackedVector&, double&, int*, int, CoinPackedVector&, CoinPackedVector&, Osi
Cuts&) const (CglKnapsackCover.cpp:722)
==1641== by 0x80AE2B7: CglKnapsackCover::generateCuts(OsiSolverInterface con
st&, OsiCuts&, CglTreeInfo) const (CglKnapsackCover.cpp:571)
==1641== by 0x807FCF7: generate_cgl_cuts(LPDATA*, int*, CUT_DATA***, char, i
nt) (lp_solver.c:3088)
==1641== by 0x808E69F: generate_cuts_in_lp_u(LP_PROB*) (lp_wrapper.c:2125)
==1641== by 0x808C13E: receive_cuts(LP_PROB*, int, int) (lp_proccomm.c:366)
==1641== by 0x8087E24: fathom_branch(LP_PROB*) (lp_genfunc.c:365)
==1641== by 0x80882E6: process_chain(LP_PROB*) (lp_genfunc.c:179)
==1641== by 0x807A48F: solve(TM_PROB*) (tm_func.c:395)
==1641== by 0x805B1A4: sym_solve(SYM_ENVIRONMENT*) (master.c:879)
==1641== by 0x804B660: main (main.c:170)

Possible bug in CglPreProcess::preProcessNonDefault in version 2.10.5.

Hello,

while digging into the CBC code I found somehting which appears to me as a bug.

Starting from line 1125, in the function:

OsiSolverInterface *
CglPreProcess::preProcessNonDefault(OsiSolverInterface &model,
int makeEquality, int numberPasses,
int tuning)

at line 1162:

originalModel_ = &model;

At line 1206:

startModel_ = originalModel_;

At line 1222:

delete startModel_;

But this way startModel_ has never been allocated.

Hope it helps.

Warning errors in VisualStudio v9

Issue created by migration from Trac.

Original creator: Gassmann

Original creation time: 2010-02-09 19:07:10

Assignee: somebody

Version: release 0.5.1

1>CglTwomir.cpp
1>cgltwomir.cpp(1067) : warning C4138: '/' found outside of comment
1>cgltwomir.cpp(1447) : warning C4138: '
/' found outside of comment
1>cgltwomir.cpp(1448) : warning C4138: '/' found outside of comment
1>cgltwomir.cpp(1449) : warning C4138: '
/' found outside of comment
1>cgltwomir.cpp(1463) : warning C4138: '/' found outside of comment
1>cgltwomir.cpp(1465) : warning C4138: '
/' found outside of comment

CglRedSplit does not compile with MV Visual Studio Version 6.

Issue created by migration from Trac.

Original creator: @jpfasano

Original creation time: 2007-04-11 14:54:35

Assignee: somebody

An instance of the specific error message is:

d:\coin\coin-cbc-all\trunk\cgl\src\cglredsplit\cglredsplitdata.hpp(57) : error C2555: 'CglRedSplitData::clone' : overriding virtual function differs from 'CglData::clone' only by return type or calling convention

d:\coin\coin-cbc-all\trunk\cgl\src\cgldata.hpp(25) : see declaration of 'CglData'

The problem is that CglRedSplitData.hpp has:

virtual CglRedSplitData* clone() const;

and CglData.hpp has

virtual CglData* clone() const;

The compiler is complaining because the return types are different.
The original C++ standard required the return types to be the same.
More recently this requirement was relaxed.
The Version 6 compiler follows the older standard.

Since the other cuts don't exhibit this compile time problem, it would seem that they have been implemented following the older standard.

Cbc is now using the RedSplit cut, so this compiler error is preventing Cbc from being used with the Version 6 compiler. Perhaps it is time to abandon support for the Version 6 compiler?

CglKnapsackCover::deriveAKnapsack asserts when leMatrixRow has 0 element

Issue created by migration from Trac.

Original creator: San

Original creation time: 2007-02-06 02:27:09

Assignee: fmargot

Version: release 0.5.1

Code asserted when attempting to transform a matrix with 0 elements. The fix is attached to this ticket.

At line 831:

    if (leMatrixRow.getNumElements() > 0)
    {
        std::transform(leMatrixRow.getElements(),
		       leMatrixRow.getElements() + leMatrixRow.getNumElements(),
		       leMatrixRow.getElements(),
		       std::negate<double>());
    }

CoinIsOrthogonal fails unless packed vector indices are in ascending order

Issue created by migration from Trac.

Original creator: @LouHafer

Original creation time: 2007-05-31 22:24:48

Assignee: somebody

CoinIsOrthogonal fails unless the vector of indices in a packed vector is sorted in ascending order. Some solvers return the indices in descending order. The following change allows CglClique::createSetPackingSubMatrix to convert descending order into ascending order as the working matrix is created. This will fail if a solver returns indices in some random order, but until one comes along, be can try to avoid a sort. This code should replace the final loop in the routine:

/*
  Now create the vectors with row indices for each column (sp_col_ind) and
  column indices for each row (sp_row_ind). It turns out that
  CoinIsOrthogonal assumes that the row indices for a given column are listed
  in ascending order. This is *not* a solver-independent assumption! At best,
  one can hope that the underlying solver will produce an index vector that's
  either ascending or descending. Under that assumption, compare the first
  and last entries and proceed accordingly. Eventually some solver will come
  along that hands back an index vector in random order, and CoinIsOrthogonal
  will break.  Until then, try and avoid the cost of a sort.
*/
   sp_col_ind = new int[nzcnt];
   sp_row_ind = new int[nzcnt];

   for (j = 0; j < sp_numcols; ++j) {
      const CoinShallowPackedVector& vec = mcol.getVector(sp_orig_col_ind[j]);
      const int len = vec.getNumElements();
      const int* ind = vec.getIndices();
      if (ind[0] < ind[len-1]) {
        for (i = 0; i < len; ++i) {
           const int sp_row = clique[ind[i]];
           if (sp_row >= 0) {
              sp_col_ind[sp_col_start[j]++] = sp_row;
              sp_row_ind[sp_row_start[sp_row]++] = j;
           }
        }
      }
      else {
        for (i = len-1; i >= 0; --i) {
           const int sp_row = clique[ind[i]];
           if (sp_row >= 0) {
              sp_col_ind[sp_col_start[j]++] = sp_row;
              sp_row_ind[sp_row_start[sp_row]++] = j;
           }
        }
      }
   }
   std::rotate(sp_col_start, sp_col_start+sp_numcols,
               sp_col_start + (sp_numcols+1));
  

Trac tickets don't have a list of components

Issue created by migration from Trac.

Original creator: @tkralphs

Original creation time: 2006-11-29 00:10:53

Assignee: somebody

Version: 1.0

Under "Ticket Properties," you can define different components (see the Admin tools page). This could help separate out bug reports by sub-project. You can also specify version numbers.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.