[Scip] variable stats

Gregor Hendel hendel at zib.de
Thu Oct 30 18:40:19 CET 2014


Hi James,

Am 30.10.2014 um 11:27 schrieb James Cussens:
> Dear Gregor,
>
> This is very helpful, many thanks. I still need to clarify a few things ...
>
>> prio: The branch priority of this variable. Only the branching candidates
>> with highest priority are branched on at a node
>> factor:
> Just to be clear. Suppose all variables are integer, and we had one
> variable x' which had a higher priority than all others, and suppose
> its value was not already fixed. Suppose further that x' had a integer
> value in the current node's LP solution, but all others had fractional
> value. One SCIP still just go ahead and branch on x' ?
Yes, this is indeed the case. The variable you describe would be 
accounted for as a pseudo branch candidate, in contrast to an LP 
branching candidate. This is why branching rules have several callbacks 
to be executed for LP-branching, pseudo candidate branching, and for 
external candidates (in case of MINLP, or if you implement your custom 
relaxation handler). Note that not all branching rules, especially the 
reliability pseudo cost branching rule, use the fractionality of 
candidates in the definition of their scoring functions, and are thus 
not applicable in this case.

In default settings, SCIP would therefore resort to inference branching 
instead.
>
>> branchings up/down: The actual number of times this variable has been
>> branched on in the respective directions.
> Naively one would expect the number of up and down branchings to be
> equal since (assuming 'normal' binary branching) two branches are
> created by branching on a variable. Is the difference in these two
> numbers due to child nodes being pruned / cut off? Or is there some
> other reason?
Yes, the branching is accounted for when the child node is actually 
processed. If exactly one of the children is pruned and the other one is 
processed, this causes a lack of symmetry in the branching counters 
(which is why there are two of them ;).
Another important reason are primal heuristics which explore (virtual) 
paths of the tree in a depth-first search manner. They usually only 
create a single child node and continue. Setting the node limit of SCIP 
to one and displaying the branching statistics shows you that already 
before the first real branching decision has been followed, some of the 
branching statistics are already non-null.

Kindly,
Gregor
>
> Best wishes,
>
> James
>



More information about the Scip mailing list