You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, it is assumed in the framework that an integral solution necessarily also leads to an integral objective function. This is for example used in determining if a node can be pruned.
Clearly, this can always be enforced by scaling of the objective coefficients, but this strategy may lead to poor performance for the LP solves in cases where the scaling factor is large. Moreover, it requires some bookkeeping of the scaling that occurs.
Clearly, a user could fix this by overriding these respective methods that use this behaviour in his implementation of the branch and price framework.
However, I would believe that this use case is so common that it would maybe be a good thing to introduce this in the framework itself, for example by using a switch that determines if this behaviour is needed.
The text was updated successfully, but these errors were encountered:
Currently, it is assumed in the framework that an integral solution necessarily also leads to an integral objective function. This is for example used in determining if a node can be pruned.
Clearly, this can always be enforced by scaling of the objective coefficients, but this strategy may lead to poor performance for the LP solves in cases where the scaling factor is large. Moreover, it requires some bookkeeping of the scaling that occurs.
Clearly, a user could fix this by overriding these respective methods that use this behaviour in his implementation of the branch and price framework.
However, I would believe that this use case is so common that it would maybe be a good thing to introduce this in the framework itself, for example by using a switch that determines if this behaviour is needed.
The text was updated successfully, but these errors were encountered: