[Scip] Design choices

[Stefan Lörwald]

Hi Gerald,

I don't think I can agree with that.

  > If you would invest some more time to write the code which generates
the solution itself instead of just its objective value (which you would
probably do after the objective limit experiments show that a heuristic is
promising), you would get the same behavior: [...]

Most definitively not. Adding the (already optimal) solution data results
in a solved problem. Setting the optimal value as ObjLimit results in
infeasibility.

Heuristics may find the optimal value, so allowing the best solution to be
equal in value to the heuristic isn't "underestimating the positive effect
of the heuristic", but _enabling_ the heuristic to be correct.

I _don't_ say that the implementation of SCIPsetObjlimit is false or bad.
It's _not intuitive_.

> [...] because nodes with a lower bounds equal to the objective limit
would still need to be processed.

That would be the use case of my proposed SCIPsetStrictObjLimit().

> This has nothing to do with being consistent with how constraint work
[...]

Of course it does. The naming does not imply strictness. Hence it is
non-obvious that this should be different from a manually implemented
constraint on the objective value. This should do the same, but it simply
doesn't.

> it is just the way an objective limit works within SCIP and probably
works within every MIP solver

CPLEX doesn't.

>  , unless you want to do additional work and deteriorate your
performance.

I don't. I've already proposed an alternative. There's no downside at all.
No additional work, no reduced performance.

Please recall that I don't want to change your ways and do not intend to
break your habits. I'm just curious about what led to these decisions.

Best regards,
Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserv.zib.de/mailman/private/scip/attachments/20130629/647bdc41/attachment.html