Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remove assumption of integer objective, fixes #23 #24

Open
wants to merge 3 commits into
base: development
Choose a base branch
from

Conversation

rowtricker
Copy link

@rowtricker rowtricker commented Nov 25, 2016

fixes #23

This does make that the incumbent solution is now stored as a double. Alternatively, to prevent a loss of precession, it might be better to store an integer if the property is selected. Any thoughts on this?

&& Math.floor(node.bound + config.PRECISION) <= lowerBoundOnObjective);
} else {
return optimizationSenseMaster == OptimizationSense.MINIMIZE
&& node.bound >= upperBoundOnObjective
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this bit is tricky. It doesn't take the precision into account. I need to read up on this topic to decide what is the best comparison.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was also not entirely sure what to do here either. However, allowing to deviate by the precision would mean that this would be allowed recursively if the nodes are pruned. Hence, the final precision could turn out significantly worse than the given precision. That was my reason for not taking it into account here.

@@ -36,7 +36,7 @@
/** Bound on this node **/
public final double nodeBound;
/** Best integer solution discovered so far **/
public final int bestIntegerSolution;
public final double bestIntegerSolution;
Copy link
Collaborator

@jkinable jkinable Nov 28, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this variable should probably be renamed, as it is no longer an integer solution. I would change it to:
objectiveIncumbentSolution (that would probably make it more consistent as well)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, the term integer solution is somewhat vague anyhow as the integrality could refer to both the objective value as well as the integrality of the solution itself. I will change this.

@@ -46,7 +46,7 @@
* @param nodeBound Bound on the node
* @param bestIntegerSolution Best integer solution discovered thus far
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

description needs update

@@ -33,7 +33,7 @@
* Best available integer solution at the start of the Branch-and-Price or Column generation
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

descr needs update

@@ -77,7 +77,7 @@
* is a maximization problem, the Colgen procedure is terminated if
* {@code floor(boundOnMasterObjective) <= cutoffValue}.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

desr needs update

@@ -77,7 +77,7 @@
* is a maximization problem, the Colgen procedure is terminated if
* {@code floor(boundOnMasterObjective) <= cutoffValue}.
**/
protected int cutoffValue;
protected double cutoffValue;
/**
* Bound on the best attainable objective value from the master problem. Assuming that the
* master is a minimization problem, the Colgen procedure is terminated if
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

descr needs update

return Math.floor(boundOnMasterObjective + config.PRECISION) <= cutoffValue;
} else {
if (optimizationSenseMaster == OptimizationSense.MINIMIZE)
return boundOnMasterObjective >= cutoffValue;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Check: how to handle precision correctly.

@@ -55,7 +55,7 @@
/** Name of the instance being solved **/
protected String instanceName;
/** Best integer solution obtained thus far **/
protected int bestIntegerSolution;
protected double bestIntegerSolution;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Best to rename this to: objectiveIncumbentSolution
Also, please update descr

@@ -122,6 +125,8 @@ public static void readFromFile(Properties properties)
public final boolean EXPORT_MODEL;
/** Define export directory for master models. Default: ./output/masterLP/ **/
public final String EXPORT_MASTER_DIR;
/** Defines if an integer solution has an integer objective. Default = true */
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest to be a bit more verbose here:
Defines whether the objective value of any feasible solution is an integer value. More precisely, this value should be set to true if all coefficients in the objective function are integer values, and all variables in the objective function are integer variables. This parameter influences the rounding and pruning behavior in a Branch-and-Price application.

System.out.println("Solution for : " + instance + " is: " + solution);
Assert.assertEquals(solution, instances.get(instance).intValue());
Assert.assertEquals(solution, instances.get(instance).intValue(), 0.000001);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use Config.PRECISION

@rowtricker
Copy link
Author

All comments (that can be directly fixed on my side) have been added in the last commit.

@jkinable
Copy link
Collaborator

I still haven't found a good solution on how to handle the precision correctly. This will require some more digging...

@rowtricker
Copy link
Author

I understand. Would it be a good idea to take a quick glance at how related frameworks are handling this?

@rowtricker
Copy link
Author

I found an additional assumption of an integer objective in AbstractBranchAndPrice, which would throw an exception in case the objective is non-integer when trying to round. It has been addressed by the above commit.

@CLAassistant
Copy link

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

@ncabrera10
Copy link

Hi,

I'm facing a similar problem. What checks are missing to merge this with the master branch?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants