<div dir="ltr">Hi Timo,<div><br></div><div>if the user requires binary variables any solution having non-binary results are per definition infeasible.</div><div>Therefore SCIP shouldn't report 0.9999999 as a feasible solution (even w.r.t. tolerances), if it isn't 0/1 feasible.</div>

<div>Either it should report as infeasible because the best value (0.999999) doesn't satisfy the 0/1 constraint, or it should report as infeasible because rounding to 1 would be infeasible.</div><div><br></div><div>However I'd very much like to actually see a case in which 0.9999999 is feasible, but 1 is not. Do you have an example at hand?<br>

<div class="gmail_extra"><br></div><div class="gmail_extra">Stefan</div><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

One amendment to Stefan's reply:<br>
<div class="im">> There is a small thing SCIP could do better actually: sometimes you'll get<br>
> 0.9999999 instead of 1 (which is representable as double) for e.g. binary<br>
> variables. In theory such output could be enforced to 0/1 or integral<br>
> value once the solving process is completed.<br>
<br>
</div>This is not correct in general. As argued below, it might be that the<br>
0.9999999 solution is feasible (w.r.t. tolerances), whereas the 0/1<br>
solution is not.</blockquote></div></div></div></div>