[Scip] best solution is not feasible in original problem

[Ramón Casero Cañas]

Dear all,

Sorry to bother you again, but a couple results more that I don't
understand.

With the attached model, in scip-3.1.0.linux.x86_64.gnu.opt.spx with
parameters

set limits time 300
set limits solutions 1
set numerics feastol 1.0037e-10

I get a solution within 2.4 sec, but with the message

  2.4s|     1 |     0 | 32458 |     - |2458k|   0 |   0 | 139 | 205 | 139
|1703 |1669 |   0 |   0 |-2.225883e+04 |-2.049845e+04 |   8.59%
  2.4s|     1 |     1 | 32458 |     - |2458k|   0 |   0 | 139 | 205 | 139
|1703 |1669 |   0 |   0 |-2.225883e+04 |-2.049845e+04 |   8.59%

SCIP Status        : solving was interrupted [solution limit reached]
Solving Time (sec) : 2.41
Solving Nodes      : 1
Primal Bound       : -2.04984451262525e+04 (1 solutions)
Dual Bound         : -2.22588342256900e+04
Gap                : 8.59 %
  [linear] <c83>:  +0.0781485688398752<x91>[C] +0.0698489436914697<y91>[C]
+0.0680134372629892<z91>[C] >= 2.50934406412487e-10;
violation: left hand side is violated by 2.50934366513847e-10
best solution is not feasible in original problem


This is not the same case as with the feasibility tolerance from yesterday,
is it? If I write the solution to a file, it comes out as a perfectly valid
solution.


************************

The second issue is that if I look at a constraint, e.g. c89, in the PIP
file that I'm providing,

c89: -0.166666666666667 x88 y91 z41 + 0.166666666666667 x91 y88 z41 +
0.166666666666667 x88 y41 z91 + -0.166666666666667 x41 y88 z91 +
-0.166666666666667 x91 y41 z88 + 0.166666666666667 x41 y91 z88 >=
2.50934406412487e-10

and after reading it in SCIP, using display problem, I see

  [nonlinear] <c89>: ( -0.16666666666666699048 * <x88> * <y91> * <z41>
+0.16666666666666699048 * <x91> * <y88> * <z41> +0.16666666666666699048 *
<x88> * <y41> * <z91> -0.16666666666666699048 * <x41> * <y88> * <z91>
-0.16666666666666699048 * <x91> * <y41> * <z88> +0.16666666666666699048 *
<x41> * <y91> * <z88>) >= 2.50934406412487e-10;


I thought that if I provide the scalar

-0.166666666666667

and the internal representation has more precision, I'd get

-0.16666666666666700000

instead of

-0.16666666666666699048

Is this also to be expected?

Best regards,

Ramon.

-- 
Dr. Ramón Casero Cañas

Institute of Biomedical Engineering
Department of Engineering Science, University of Oxford
Old Road Campus Research Building, Headington
Oxford
OX3 7DQ
UK

tlf         +44 (0) 1865 617716
twitter   @Ramon_Casero
web      http://www.cs.ox.ac.uk/people/Ramon.CaseroCanas/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserv.zib.de/pipermail/scip/attachments/20140527/03371797/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: model-tp35dfa272_6870_467a_ad0d_e06a4127cadd.pip
Type: application/octet-stream
Size: 426890 bytes
Desc: not available
URL: <http://listserv.zib.de/pipermail/scip/attachments/20140527/03371797/attachment.obj>