I recently ran into a case that caused Clp to generate a floating point divide by zero error (my code sets up signal handlers at run time to trap unexpected floating point errors).
The problem has a few hundred variables, 4 constraints, and is infeasible.
The issue occurs in Clpsimplex.cpp during the calculation of useError:
For this case useError is computed 3 times, the third time maximumAbsElement returns 0.0 and causes the divide by zero (see debug output below).
If floating point exception trapping is turned off Clp correctly reports this problem as infeasible and gives identical results to what I get if I modify the computation of useError to use:
which maintains the existing Clp behavior, since the only use of useError is in the check "useError > 1.0e-3", and avoids the possibility of a divide by 0.
Can the Clp computation of useError be updated to avoid the possible divide by zero, unless you think there is a more significant issue that should be investigated?
Thanks.
Dave
Debug output, after a call to handler_->setLogLevel(5000), with values
returned by maximumAbsElement added (output is from Clp version 1.16, revision
2256 (revision to 1.16.10), but the calculation of useError is the
same in the most current release, 1.17.3):
Result returned by maximumAbsElement: 6.90368e+20
Clp0060I Primal error 131072, dual error 2.0980835e-05
Clp0103I Primal nonlinear change 0 (5)
Largest given infeasibility 1.01892e+21 now 1.01892e+21
Result returned by maximumAbsElement: 1.01892e+21
Clp0060I Primal error 0, dual error 1.9073486e-06
Clp0018I 4 total structurals rejected in initial factorization
Clp0103I Primal nonlinear change 1.1228831e+21 (4)
Largest given infeasibility 1.01892e+21 now 5.6142e+10
Result returned by maximumAbsElement: 0
Floating point exception occurs in computation of useError.
Hi,
I recently ran into a case that caused Clp to generate a floating point divide by zero error (my code sets up signal handlers at run time to trap unexpected floating point errors).
The problem has a few hundred variables, 4 constraints, and is infeasible.
The issue occurs in Clpsimplex.cpp during the calculation of useError:
double useError = CoinMin(largestPrimalError, 1.0e5 / maximumAbsElement(solution, numberRows + numberColumns));
For this case useError is computed 3 times, the third time maximumAbsElement returns 0.0 and causes the divide by zero (see debug output below).
If floating point exception trapping is turned off Clp correctly reports this problem as infeasible and gives identical results to what I get if I modify the computation of useError to use:
which maintains the existing Clp behavior, since the only use of useError is in the check "useError > 1.0e-3", and avoids the possibility of a divide by 0.
Can the Clp computation of useError be updated to avoid the possible divide by zero, unless you think there is a more significant issue that should be investigated?
Thanks. Dave
Debug output, after a call to handler_->setLogLevel(5000), with values returned by maximumAbsElement added (output is from Clp version 1.16, revision 2256 (revision to 1.16.10), but the calculation of useError is the same in the most current release, 1.17.3):
Clp0006I 0 Obj 0 Primal inf 5.6144408e+10 (4) Clp0102I 2 3.3771497e+21 In: C84 Out: R1 dj ratio -3.6952737e+16 distance 6.0168037e+10 Clp0060I Primal error 71.611824, dual error 0 Clp0006I 2 Obj 3.3771497e+21 Primal inf 1.2393906e+19 (4) Clp0106I Btran alpha -4.7683716e-07, ftran alpha 0 Clp0010I Flagging variable C276 Clp0102I 3 5.2177942e+23 In: C258 Out: C84 dj ratio -5.7094609e+18 distance 14028794 Clp0102I 4 3.9634134e+24 In: C301 Out: R3 dj ratio -2.5457394e+19 distance 135001.38 Clp0102I 5 1.0927608e+25 In: C168 Out: R0 dj ratio -3.7776044e+19 distance 34117.21 Clp0106I Btran alpha 1.0000063, ftran alpha 1 Clp0060I Primal error 119969.38, dual error 0.8174084 Clp0006I 5 Obj 1.092752e+25 Primal inf 3.9579645e+22 (4) Clp0106I Btran alpha 1.0000007, ftran alpha 1 Clp0102I 6 1.092752e+25 In: C302 Out: C301 dj ratio -6.6056814e+19 distance 0.016396321 Clp0106I Btran alpha 1.0000049, ftran alpha 1 Clp0060I Primal error 119977.55, dual error 0.53346012 Clp0006I 6 Obj 1.092752e+25 Primal inf 3.9579645e+22 (4) Dual inf 0.43370091 (6) Clp0060I Primal error 119977.55, dual error 0.53346012 Clp0102I 7 1.092752e+25 In: C301 Out: C302 dj ratio -6.6056814e+19 distance 0.08130929 Clp0102I 8 1.0927565e+25 In: C259 Out: C258 dj ratio -1.3548291e+20 distance 0.35547982 Clp0060I Primal error 256339.71, dual error 0.29017714 Clp0006I 8 Obj 1.0927662e+25 Primal inf 3.9579995e+22 (4) Dual inf 1.9491607 (9) Clp0060I Primal error 513704.88, dual error 0.29017714 Clp0103I Primal nonlinear change 0 (6) Largest given infeasibility 6.90368e+20 now 6.90368e+20
Result returned by maximumAbsElement: 6.90368e+20 Clp0060I Primal error 131072, dual error 2.0980835e-05 Clp0103I Primal nonlinear change 0 (5) Largest given infeasibility 1.01892e+21 now 1.01892e+21
Result returned by maximumAbsElement: 1.01892e+21 Clp0060I Primal error 0, dual error 1.9073486e-06 Clp0018I 4 total structurals rejected in initial factorization Clp0103I Primal nonlinear change 1.1228831e+21 (4) Largest given infeasibility 1.01892e+21 now 5.6142e+10
Result returned by maximumAbsElement: 0