[Coin-lpsolver] Clp and cbc consttants in code.

John J Forrest jjforre at us.ibm.com
Sun Oct 14 18:42:21 EDT 2007


William,

Thank you for your comments.

Looking for floats in Cbc, Clp, CoinUtils and some of Cgl  I could only 
find a float defined in ClpSimplex.?pp.  The use there seems safe but I 
will change in trunk.  The FLT_MAX in CbcfathomDynamicProgramming.cpp is 
DBL_MAX in trunk (I will change to COIN_DBL_MAX as that is preferred). 
Where else did you find floats?

As for the matter of many constants,  I plead guilty.  I have a tendency 
to pluck a number from the air depending on the direction of the wind.  Of 
more concern is that probably tolerances are not rigorously used e.g. 
value < tolerance is not the negation of value > tolerance.  However it 
would probably take a month or two to clean up the code for this and for 
double constants and it would not be very amusing.

Anyone willing to volunteer?  Somehow I doubt it.

John Forrest



"William H. Patton" <pattonwh at comcast.net> 
Sent by: coin-lpsolver-bounces at list.coin-or.org
10/14/2007 01:51 PM
Please respond to
pattonwh at comcast.net


To
<coin-lpsolver at list.coin-or.org>
cc

Subject
[Coin-lpsolver] Clp and cbc consttants in code.






I am new to cbc. I have just compiled CBC in VS8
Cbc-1.1.0-win32-msvc8.

I am surprised to see the warnings about implicit conversion of
double to float in Cbc-1.1.0-win32-msvc8.  It is clear that floats
are intentionally used. Is the memory used so large as to need
this? If so, I think it would be safer to use a CBC private type
so the assignment overload can pass thru protective code to deal
carefully with the too large exponents.  I think particularly
about the 1.0e+100 apparent infinity of clp constants.
CbcBranchActual.cpp(2141): double bestEstimate = 1.0e100;
CbcBranchActual.cpp(2139): double bestCriterion=-1.0e50;
CbcFathomDynamicProgramming.cpp(262):
CoinFillN(cost_,size_,FLT_MAX);
My compiler definitions show range limits as
#define DBL_MAX         1.7976931348623158e+308 /* max value */
#define FLT_MAX         3.402823466e+38F        /* max value */

The other source maintenance concern I have is the presence of
many constants in the code.  Attached is a list of the nearly 400
instances of doubles that I could find with an easy regex search..
I think good practice calls for these to deserve names so they can
be consistently used.  They could be #defined but better for an
API oriented extensible framework, they should have API get and
set access functions
for user tinkering. I think there are about 30 distinct values in
the 400 lines.

You may have a better search that can find the rest of the not 0
or 1 manifest constants in the code.  I see .5, .005. 0.5 swept
along in the attached search
CbcNode.cpp(2402): double upPenalty =
CoinMin(upCost[i],1.0e110)*(1.0-value);
CbcNode.cpp(2403): double downPenalty =
CoinMin(downCost[i],1.0e110)*value;
CbcNode.cpp(2443): sort[iBestGot]=-1.0e120;
CbcBranchCut.cpp(540): if (djTolerance_<1.0e10) {
CbcCompareActual.cpp(278): if (treeSize_*size>5.0e7)
CbcHeuristic.cpp(719): distance = floor(distance+1.05e-8);
assert (lower[iColumn]>-1.0e20);

I am impressed by the branch and cut performance on the test
problem that brought me to the site. I think the Feasibility Pump
is really quite a neat feature.

William

_______________________________________________
Coin-lpsolver mailing list
Coin-lpsolver at list.coin-or.org
http://list.coin-or.org/mailman/listinfo/coin-lpsolver

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/clp/attachments/20071014/bd282833/attachment.html>


More information about the Clp mailing list