Branching split up into several steps

[Wikunia]

Currently branch! is a single function I think it makes sense to split it up into:

• get_branching_variable
• branch_on_variable

or even

• get_branching_variable
• get_left_node
• get_right_node

maybe also a combination of the two is possible.
By calling the lower one as a default but allowing the way like this:

var = get_branching_variable(tree, node)
branch_on_variable(tree, node, var)

branch_on_variable(tree, node, var) = get_left_node(tree, node, var); get_right_node(tree, node, var)

this way there is a possibility to have more than two children easily.

[Wikunia]

The get_branching_variable shall also dispatch on the option branch_strategy see #4
Then for example the FIRST strategy should call:
get_relaxed_values to iterate over it and one needs to implement a is_fixed method which shall exist for float and check whether it is nearly discrete also based on some atol and rtol.

[matbesancon]

Depending on the design planned, relying on two functions for left and right node prohibits from non-binary branching.
It also reduces the possibility for common computation. In our case, we do a single processing step that produces the left and right data structure

[Wikunia]

Yeah the plan was to make that a default maybe but have the ability to do as many nodes as you wish.

[matbesancon]

the argument against would be that the interface to implement becomes
implement( left & right ) || implement( branch_on_variable )
while you could just specify that branch_on_variable must be implemented and return a collection of nodes (either a vector, static vector or tuple or something else)

[Wikunia]

Oh yeah I overlooked that that getting the branching variable could also be different.
I thought only about one variable but for exampling setting it to 1,2,3,4,5,6,7,8,9 like for a sudoku problem.