Paper: L2P-MIP: Learning to Presolve for Mixed Integer Programming (ICLR-2024)

Reviewer comment (Experiments):
While the current L2P model shows satisfactory improvements over the baselines, further performance gains may be achievable by leveraging more modern neural network architectures. For example, the authors used GCNN as the backbone of the feature-extracting GNN, which could potentially be replaced with graph-formers in a drop-in replacement manner.

Author response:
> ***Q1: Leveraging more modern neural network architectures.***
> 
> Thanks for this valuable suggestion. We did not think of this point before since GCNN is commonly used in the related work while proposing better GNN architecture is not the focus of this paper. In fact, this is also the case for the ML-for-MIP community whereby the standard GNN is largely used in literature, and there even exists papers challenging the role of GNN in solving combinatorial problems [7]. Hence how to effectively leverage GNNs for MIP is still an open problem.
> 
>On the other hand, we notice that RandomGNN [1] is a tailored approach, to add different special features to each node in the process of GNN. It can make GNN better distinguish the nodes and enhance the representation of the MIP instance. We consider this approach could be a possible improvement to existing GNN for our problem. Moreover, as the reviewer mentioned, we try to test the performance of GATConv [2] and TransformerConv [3] as drop-in replacements.
> |      | Original L2P | L2P + RandomGNN[1] | L2P + GATConv[2]   | L2P + TransformerConv[3]|
> | - | - | - | - | - |
> | CorLat | 34.74%    | 35.11% |  34.92%|   35.36%    |
> | MIK |   3.02%  | 3.08% | 2.87% |   3.03%   |
>
> Due to the short time window for response in ICLR 2024, we first test the performances of different GNN backbones on the medium datasets CorLat and MIK. It turns out the replacements of the GNN backbone can actually improve the performance of L2P, but only to a small extent. It may be because the processing of features after GNN is more valuable in L2P. We appreciate the review for the idea of adding a drop-in replacement for the GNN backbone, and we will continue to work in this direction.

Reviewer comment (Novelty):
It may be beneficial to include some related work in the literature review and experiment section. For example, I had the opportunity to review a paper titled "Accelerate Presolve in Large-Scale Linear Programming via Reinforcement Learning," which addresses the same problem but in the LP domain.

Author response:
> ***Q2: About one concurrent work.***
> 
> Thanks for your reminder, we are sorry that we did not include this paper in our submitted paper, since it was recently submitted to Arxiv after our ICLR submission. We find that this concurrent work also introduces a new method utilizing reinforcement learning for presolve, while they focus on the LP domain unlike us on the MIP domain. In fact, solving MIP is different from solving LP in many aspects [8]. For example, the branch-and-bound algorithm in MIP involves solving large batches of similar problems efficiently, and the cutting-plane method in MIP adds linear inequalities to the original problem to eliminate fractional solutions. These techniques are easily influenced by the presolving of MIP, but not required by LP. 
> 
> Specifically, they use RL to tackle the presolve decisions in the process of solving LP. Since the solving of MIP in our work is more complicated than LP, their method may focus on different aspects of the solvers, like the termination point which is critical in LP solvers. However, due to the inefficient sample utilization in RL, the proposed method in this concurrent work may need more time in trial-and-errors and still faces the challenges of sparse reward during training. 
> 
> Compared to this work, our L2P can take full advantage of samples collected in offline training and the online testing process is more stable and efficient, which is important in practical usage in our opinion. We appreciate the reviewer for mentioning this work, and we have included it in the related work of our revised paper and are thinking of further interactions with our work in the future.

Reviewer comment (Experiments):
Has the performance gain observed from SCIP also been found with other MIP solvers such as GUROBI and CPLEX?

Author response:
> ***Q3: Performance about other MIP solvers such as GUROBI and CPLEX.***
> 
> Thanks for your valuable question. Many commercial MIP solvers such as Gurobi and CPLEX are also equipped with kinds of presolving techniques. However, their APIs to adjust the presolving are not exposed since they are commercial solvers and not open-source, and that's why we can not test our proposed method on the commercial solvers. We consider it impossible to directly improve commercial solvers in research papers, as existing papers [4,5,6] mainly conduct experiments on open-source solvers (SCIP) like us. If we are able to cooperate with the commercial solver company in the future, we can also add our method to their internal strategy, integrating our machine learning technologies to help users better solve MIPs.

Reviewer comment (Experiments):
Regarding the training of the L2P model, how crucial are KRL and dynamic loss averaging? Do they significantly affect the overall trend of the results?

Author response:
> ***Q4: How crucial are KRL and dynamic loss averaging?*** 
> 
> Sorry for the confusion, we have conducted an ablation study in Section 4.4 and Figure 4 of the submitted paper. As shown in Figure 4, we remove the key components of our L2P one by one, which begins with dynamic loss averaging and KRL. As shown in the figure, removing the dynamic loss averaging and KRL will result in a nearly 5% and 10% improvement drop in CorLat, while the total improvement is merely about 35%. We are sorry that we did not emphasize enough about this ablation study. We have refined this section in our paper and please refer to it.

Reviewer comment (Reproducibility):
**Lack of Detail in Methodology:** The manuscript does not adequately detail critical components of the proposed methods, such as the loss function and the domain of labels—information which is relegated to the Appendix. Moreover, key metrics like the PD integral lack a clear mathematical definition.

Author response:
We are sorry for the confusion. The loss functions used in our methods are ListMLE for the priority and Cross-Entropy for the max-round and timing. ListMLE [1] is a loss designed for ranking, which is suitable for learning the priority since the priority denotes the order/rank of the presolvers. We understand that placing the details of the experiment in the appendix is not recommended, therefore, we have reorganized the paper structure and enriched Section 4.1 to make our experimental settings more clear, sorry again for the inconvenience.

For the definition of PD integral, the primal-dual integral in the field of mixed integer programming (MIP) is a measure used to evaluate the performance of MIP solvers. It provides a quantitative assessment of how effectively a solver bridges the gap between the primal (the best feasible solution found) and dual (a bound on the optimal solution) bounds over the course of the solution process. For its mathematics formulations, we recommend the readers to read the [documentation](https://www.ecole.ai/2021/ml4co-competition/\#metrics) of one benchmark we used. The metric section of this documentation describes the calculation of PD integral with informative figures. Here we list a more detailed breakdown, and we also place it in our revised paper:
1) Primal and Dual Solutions in MIP: In mixed integer programming, a primal solution refers to a feasible solution that satisfies all the constraints of the MIP model. The dual solution, on the other hand, is related to the bounds on the optimal solution value. In linear programming, this would be equivalent to the solution of the dual problem, but in MIP, it usually refers to a bound derived from a relaxation of the integer constraints.
2) Gap Measurement: The primal-dual integral measures how the gap between the primal and dual solutions evolves over time. This gap is the difference between the objective value of the best known feasible solution (primal) and the best known bound (dual).
3) Purpose of the Primal-Dual Integral: This measure is especially useful in understanding the efficiency of a solver in converging to the optimal solution. It can highlight whether a solver quickly identifies good feasible solutions and tight bounds or whether it struggles to improve the primal and dual solutions over time.
4) Calculation: The primal-dual integral is calculated by integrating the gap over the time taken for the computation. A lower integral value indicates a more effective solver, as it shows that the solver was able to keep the primal-dual gap smaller throughout its run.
5) Use in Analysis and Benchmarking: This metric is valuable for comparing different solvers or solution strategies in mixed integer programming. It provides insights beyond just the final solution quality or computation time, focusing on the overall trajectory of the solution process.

Reviewer comment (Evaluation):
**Reporting of Metrics:** The paper uses the arithmetic mean to report solving times, which could be skewed by outliers. The geometric mean is a standard in the MIP community for its robustness to extreme values, and its absence is felt in the current reporting.

Author response:
Thanks for your kind reminder. Here, we consider the geometric mean may not be suitable for the task in our paper. In our learning to presolve task, we focus on the solving time/PD integral improvement compared to the default via presolving instead the solving time/PD integral itself. Therefore, we care for the average improvement, while we do not care whether the actual value of the solving time/PD integral is small or large, which already avoids the case of outliers if an instance is too simple or too hard. Moreover, the solving time/PD integral improvement of each instance could be zero or negative, while the geometric mean requires all terms to be positive.

Reviewer comment (Experiments):
**Comparison and Ablation Studies:** The presolving time is only provided for the L2P method. For a comprehensive understanding of efficiency, it would be beneficial to see these times for other compared methods. Additionally, the specific benefits of KRL are not clear. An ablation study to evaluate the impact of KRL would be informative.

Author response:
Thanks for your suggestion. For the running time of methods, L2P/FBAS/SMAC3 shares a similar running time. For each instance, they need less than 0.05s in the medium datasets, and less than 0.5s in the hard datasets, while the SA needs hours in the medium datasets and days in the hard datasets. Here what we want to claim is that the consumption of SA is unacceptable. Since the time usages of L2P/FBAS/SMAC3 are already enough for practical usage, we consider it acceptable that our L2P does not have a significant speed advantage over baselines. 

As for the ablation study of KRL, actually we have an ablation study in Section 4.4 and Figure 4 of the submitted paper. As shown in Figure 4, we remove the key components of our L2P one by one, which begins with dynamic loss averaging and KRL. As shown in the figure, removing the dynamic loss averaging and KRL will result in a nearly 5% and 10% improvement drop in CorLat, while the total improvement is merely about 35%. We are sorry that we did not emphasize enough about this ablation study. We have refined this section in our uploaded paper.

Reviewer comment (Experiments):
**Experimental Details:** The number of instances evaluated in Table 1 is unclear. More detailed comparisons, including the time taken during the Running Step for each method, would strengthen the results section. In Table 4, the metric used and the number of instances in each problem family should be stated for clarity.

Author response:
Sorry for the confusion, we have refined Section 4.1 and clarified our experimental settings. Specifically: For the easy datasets, we generate 1000 instances for each. For the two industrial datasets, they contain 1000 instances for each. For the medium and hard datasets, we directly split the instances provided by their original benchmarks. Here we list these datasets and their total number of instances: Corlat(2000) [2], MIK(100) [3], Item Placement(10000) [4], Load Balancing(10000) [4], Anonymous(118) [4]. The usage of datasets is common in existing papers and we just follow them [5,6,7,8]. The running time is shown in Q3. As for Table 4, the settings are the same as the main experiments in Table 1, including the number of instances and the metric. It was our negligence and we have improved the description of datasets (Section 4.1.1) in our revised paper.

Reviewer comment (Reproducibility):
**Default Parameters:** For reproducibility, could the default parameters (42 x 3) be listed explicitly in the Appendix (Table 5)?

Author response:
Thank you for your advice, we have placed the default parameters in Table 9, please refer to it.

Reviewer comment (Presentation):
**Neural Network Representation:** Figure 3 is unclear as it suggests that a neural network is derived from an MLP, which is already a type of neural network. Could this be clarified?

Author response:
Sorry for the confusion. Here the arrow in Figure 3 denotes the flow of data and how it passes through the inside modules in our framework, we did not mean to derive a network. We have refined it in its caption.

Reviewer comment (Experiments):
**Priority Label Input:** Have the authors considered using Priority Label as an input, akin to teacher forcing, and could this approach be compared with the current methodology?

Author response:
Thanks for your suggestion. During our attempts, we tested using ground truth priority as labels to see the training results of max-rounds and timing. As a result, the loss of learning max-rounds and timing goes down quicker than before. However, this approach can not be used in the real world since it needs extra ground truth priority information, which leads to an unfair comparison to the methods in our paper. Therefore, we do not regard this method as a baseline.

Reviewer comment (Writing):
**Section Clarity:** In Section 4.2, the fifth sentence needs grammatical correction. Additionally, could Section 4.3 further elaborate on the potential privacy issues mentioned?

Author response:
Thanks for your kind reminder. We have further refined our paper, added the description of PD integral (mentioned by Q1), described the setting in Table 4, corrected several sentences, reorganize the sturture of Section 4 (Experiments), and improved the text of the appendix. For the potential privacy issue mentioned in Section 4.3, it is due to the policy of the company that provides us with private industrial datasets. Due to its policy, its dataset can only be used on their computer, and the code for running must also be authorized. Therefore, deploying SMAC3 and FBAS on their computers may be troublesome. In this sense, the potential privacy is more like business sensitivity.

Reviewer comment (Presentation):
**Table Details:** In Table 4, the metric used and the number of instances in each problem family should be stated for clarity.

Author response:
Sorry for the confusion, we have refined Section 4.1 and clarified our experimental settings. Specifically: For the easy datasets, we generate 1000 instances for each. For the two industrial datasets, they contain 1000 instances for each. For the medium and hard datasets, we directly split the instances provided by their original benchmarks. Here we list these datasets and their total number of instances: Corlat(2000) [2], MIK(100) [3], Item Placement(10000) [4], Load Balancing(10000) [4], Anonymous(118) [4]. The usage of datasets is common in existing papers and we just follow them [5,6,7,8]. The running time is shown in Q3. As for Table 4, the settings are the same as the main experiments in Table 1, including the number of instances and the metric. It was our negligence and we have improved the description of datasets (Section 4.1.1) in our revised paper.