Pith. sign in

REVIEW 3 major objections 6 minor 30 references

The Maximum Common Subgraph Problem: A Portfolio Approach

T0 review · 3 major / 6 minor · reviewed 2026-08-14 · deepseek-v4-flash

Pith's one-line read A portfolio that runs several CPU and GPU solvers at once solves more maximum-common-subgraph instances than any single variant tested.

desk verdict A useful CUDA + portfolio extension of McSplit, but the portfolio's dominance claim needs a resource-normalized baseline before it can be taken at face value. read the letter →

arxiv 1908.06418 v1 pith:WJXTU75S submitted 2019-08-18 cs.DS

classification cs.DS MSC 05C6005C8568R1068W10
keywords maximumcommonsubgraphMcSplitbranchandboundparallelcomputingCUDAGPUportfolioalgorithmsgraphisomorphism
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper claims that the exact maximum common subgraph problem, which is NP-hard and already computationally unfeasible at around 40 vertices without extra information, can be tackled more effectively by a portfolio that runs several variants of the McSplit branch-and-bound procedure in parallel instead of betting on one. It reports multi-core and GPU (CUDA) implementations, plus heuristics that reorder the adjacency matrix, predict dead-ends, and restart the search, and then combines them in an online portfolio. In experiments on 2,750 small and 240 medium graph pairs from a standard benchmark database, the portfolio solves more instances within 10-second and 1,000-second limits than any individual sequential or parallel version. If the claim holds, the practical message is that heterogeneous hardware can be used as a solver strategy rather than just as a speed-up device.

What carries the argument

The load-bearing object is McSplit's branch-and-bound search driven by label classes: a vertex pair can enter the mapping only if the two vertices share the same label, meaning the same adjacency pattern to already mapped vertices, and the pruning bound is computed by Equation (1) as the current mapping size $|M|$ plus, for every label class, the smaller of the numbers of remaining vertices in the two graphs carrying that label. On top of this the paper adds a thread pool with a priority task queue for the CPU, an explicit stack of compact bidomain records for the GPU, three heuristics (block-oriented adjacency matrix reordering, dead-end forecasting with bound correction, and randomized restarts), and finally the portfolio vP, which runs several engines concurrently and lets the first finisher decide.

What would settle it

Run the same seven versions plus the portfolio on a different benchmark family, for example directed, labeled, or 50-100 vertex pairs, with multiple random seeds, and record cumulative solved counts under 10-second and 1,000-second limits; if any single version matches the portfolio, or if changing seeds reverses the ordering, the paper's dominance claim would be refuted.

Watch

Extended reading notes

Core claim

On the paper's own terms, the discovery is that none of the individual McSplit variants dominates: different heuristics win on different instances, CPU parallel versions are strongest on easy and medium cases, and the GPU version, though slow to start, overtakes CPU versions on harder cases. Because these strengths are complementary, the paper proposes a portfolio, vP, in which all engines run concurrently under a Python orchestrator and algorithm selection happens online, by whichever process finishes first. The paper reports that this portfolio is faster on average and solves more instances than any other method on both wall-clock time and graph-size ranges tested.

Load-bearing premise

The load-bearing premise is that the tested benchmark slice, undirected, unlabeled graph pairs with up to 50 vertices from the ARG database, represents real maximum-common-subgraph workloads well enough that solving more of them within time limits is a genuine general benefit.

Editorial extensions

If this is right

  • The portfolio vP solves more instances within wall-clock limits and is faster on average than every individual version tested.
  • The multi-core version speeds up McSplit without changing its search behavior, with speedups approaching an order of magnitude on harder instances.
  • The GPU version is uncompetitive on small and easy instances because of fixed transfer and launch overhead, but becomes faster than CPU versions in the tested harder range.
  • The new heuristics do not improve average runtime by themselves; their value is that each wins on a distinct subset of instances, which is exactly what makes the portfolio win overall.
  • Dead-end prediction converts long unproductive searches into bound refinement, either by raising the bound or by binary search between known lower and upper bounds.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Because the paper's runtime data are single runs of a randomized restart procedure, a natural test is to run the portfolio with several seeds; variance in heavy-tailed distributions could change the exact ordering even if the portfolio's complementarity persists.
  • The same online portfolio recipe, run CPU and GPU engines concurrently and let the first finisher win, could transfer to other recursive search problems such as subgraph isomorphism, connected MCS, or SAT, where portfolio methods currently rely heavily on offline algorithm selection.
  • The matrix-reordering heuristic based on block triangularization suggests a cheap feature, component block structure, that could feed a per-instance scheduler mixing offline selection with online racing.
  • The portfolio's dominance is demonstrated only on undirected, unlabeled graphs up to 50 vertices, so extending the same race-based design to labeled, directed, or larger instances is an untested but promising direction.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 6 minor

Summary. The paper extends the McSplit branch-and-bound algorithm for the maximum common subgraph problem to parallel multi-core CPU and CUDA GPU implementations. It introduces three heuristics: adjacency-matrix reordering, dead-end prediction with bound correction, and randomized restarts. It then proposes a portfolio (vP) that runs sequential, multi-core CPU, and GPU variants concurrently under a Python orchestrator. Experiments on a subset of the ARG benchmark (2,750 small and 240 medium undirected unlabeled graph pairs) are used to claim that vP is faster on average and solves more instances than any individual version.

Significance. If the central empirical claim were established with proper controls, the paper would offer practical engineering insights for parallelizing branch-and-bound MCS solvers, particularly the GPU adaptation and the online portfolio. The paper is transparent about algorithmic details and shows that the individual heuristics do not improve average performance (Fig. 11), which is an honest limiting result. However, the headline claim about the portfolio rests on a comparison that is not resource-normalized and on single-run randomized measurements, so the current evidence does not fully support the conclusion.

major comments (3)
  1. [V-C, Fig. 12] The comparison is not resource-normalized. vP simultaneously uses the sequential pre-run, the 8-thread CPU pool (via v2/v4), and the GPU (via v5), while each baseline (mc1, mc2, v2, v5) uses only a single engine/hardware type. The paper explicitly notes that CPU and GPU versions run on separated platforms to avoid bandwidth contention, confirming that vP consumes strictly more hardware than any individual alternative. The superior wall-clock performance of vP could therefore be an artifact of using more hardware rather than of the portfolio's online selection or modified engines. A trivial control that runs mc2 and v5 concurrently and returns the first result is never evaluated; without it, the portfolio claim is unsupported as stated.
  2. [IV-A and Figs. 6-12] The restart heuristic is explicitly randomized (''random selection of the another tree branch''), and vP includes versions augmented with this heuristic. Yet every data point in the cumulative plots comes from a single run, with no variance statistics, confidence intervals, or repeated-run medians. MCS solver runtimes are known to be heavy-tailed, and a single run can change the ordering of methods, especially for randomized algorithms. The authors should report repeated runs with different random seeds and present medians and a spread measure for the randomized versions and for vP.
  3. [V-A and V-C] Several thresholds (PART_LEVEL, the dead-end recursion threshold, the restart trigger factor, the portfolio pre-run time, thread-pool size) are hand-tuned, and the evaluation is performed on the same ARG subset used to observe these settings, with no training/test separation or cross-benchmark robustness check. The concluding claim in Section VI that ''the portfolio approaches is beneficial in the domain'' is therefore only supported for this particular benchmark subset and configuration. A sensitivity analysis over the thresholds and an evaluation on at least one additional benchmark family (e.g., directed or labeled graphs) would be needed to support the general claim.
minor comments (6)
  1. [V-B, Fig. 8] The text states that the plot covers ''the small and the medium graph sets considered together,'' but the y-axis maximum is 80, which cannot represent the combined 2,990 instances; the caption should state which subset is actually shown.
  2. [III-A] In the paragraph describing the thread pool, ''the the working thread'' should be ''the working thread.''
  3. [V-C] ''in the time range fro 0 to 10 seconds'' should be ''from 0 to 10 seconds.''
  4. [VI] ''the portfolio approaches is beneficial'' should be ''the portfolio approach is beneficial.''
  5. [IV] ''orchestrated by a a Python interface'' should be ''by a Python interface.''
  6. [Throughout] The name ''McCreesh'' is sometimes spelled ''Mc Creesh'' (e.g., Section IV-A); please unify the spelling.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper reports direct empirical comparisons and imports the McSplit bound from prior work rather than deriving it from its own conclusions.

full rationale

The paper makes no theoretical derivation chain to audit: Equation (1), the McSplit bound, is taken directly from McCreesh et al. [3] as an external building block, and the paper's contributions are engineering modifications plus measured performance comparisons. The headline claim that vP is 'faster on average and able to solve more instances than any other method' (Section V-C, Fig. 12) is a direct experimental observation on a fixed ARG benchmark subset, not a quantity predicted from fitted parameters or from the paper's own definitions. Heuristic thresholds such as PART_LEVEL, the dead-end recursion threshold, and the 5-to-10 second portfolio pre-run time are hand-set and evaluated on the same benchmark family, which raises an in-sample evaluation concern but not circularity: the reported improvements are measurements, not outputs that were forced to equal the heuristic settings by construction. Likewise, vP's simultaneous use of CPU and GPU resources is a fairness-of-comparison issue, not a circularity issue. The only self-citation, reference [20], is used to support the background statement that portfolios succeed in model checking and SAT competitions; it is not load-bearing for the MCS results and does not import an unverified uniqueness or correctness claim. No step in the paper reduces to its own input by definition, so the appropriate finding is no significant circularity.

Assumptions & free parameters 6 free parameters · 6 assumptions · 0 invented entities

The central empirical claim rests on a handful of hand-tuned thresholds and on the correctness of the underlying McSplit bound. The parallel and GPU versions assume that the shared incumbent and the iterative stack preserve the exact search semantics of the recursive algorithm, but no formal proof is supplied. The heuristics' thresholds are tuned on the same ARG benchmark set used for evaluation, so the measured gains are partly in-sample. No new physical or formal entities are postulated.

free parameters (6)
  • PART_LEVEL (task delegation depth threshold) = CPU depth 5 before GPU delegation (per Section V-B); exact CPU-only threshold not specified
    Controls how many recursion levels are processed on the CPU before tasks are handed to worker threads or GPU; affects load balance and overhead. Chosen by tuning, not derived.
  • dead-end recursion threshold
    Number of recursions without incumbent improvement that triggers dead-end prediction. The paper says the threshold 'can be evaluated using absolute values or by taking into consideration the number of recursions that led to the last increment of the bound', but no specific value is reported; it is tuned on the benchmark data.
  • bound increment amount = usually 1 or doubling
    When a dead-end is predicted, the bound is increased by a small value or doubled before a binary search. The choice of increment is a heuristic parameter.
  • restart trigger factor = 2x recursions since last improvement
    A restart is triggered when the recursion count doubles relative to the count at the last larger MCS. This factor is hand-picked.
  • portfolio sequential pre-run time = 5 to 10 seconds
    The Python orchestrator runs only sequential versions for a few seconds before launching parallel CPU and GPU versions; this delay is a tunable parameter.
  • thread pool size = 8 (logical cores of i7 4790K)
    Number of worker threads is set to the number of logical CPU threads; hardware-dependent.
assumptions (6)
  • domain assumption McSplit is correct and its bound (Eq. 1) is an admissible upper bound for the maximum common induced subgraph.
    The entire parallel and GPU work builds on McSplit's pruning; if the bound were inadmissible, pruning could discard optimal solutions.
  • domain assumption The shared-memory parallelization preserves the completeness of the branch-and-bound search: no branch containing a better solution is pruned because of stale or inconsistent shared state.
    The paper relies on atomic variables for the shared incumbent but provides no proof that race conditions cannot cause a valid branch to be skipped.
  • domain assumption The iterative stack representation of the search tree is semantically equivalent to the original recursive McSplit traversal.
    The GPU version replaces recursion with a byte-coded bidomain stack; no equivalence proof is given, only a design description.
  • domain assumption The ARG database subset is representative of practical MCS instances.
    The empirical conclusions generalize only if this benchmark slice captures typical difficulty.
  • domain assumption Single-run timing measurements are meaningful for these heavy-tailed runtimes.
    No repeated runs or confidence intervals are reported; variance could change conclusions.
  • ad hoc to paper Hellerman-Rarick reordering improves search on the tested graphs.
    The paper assumes that permuting the adjacency matrix with this sparse-matrix ordering produces better search trees for MCS; this is only evaluated empirically on the same dataset.

how reviews work

0 comments
Cite this review

Pith. "Pith review of The Maximum Common Subgraph Problem: A Portfolio Approach." pith.science (2026). https://pith.science/paper/WJXTU75S

@misc{pith2026190806418,
  author       = {Pith},
  title        = {Pith review of: The Maximum Common Subgraph Problem: A Portfolio Approach},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/WJXTU75S}},
  note         = {Machine review of arXiv:1908.06418}
}
read the original abstract

The Maximum Common Subgraph is a computationally challenging problem with countless practical applications. Even if it has been long proven NP-hard, its importance still motivates searching for exact solutions. This work starts by discussing the possibility to extend an existing, very effective branch-and-bound procedure on parallel multi-core and many-core architectures. We analyze a parallel multi-core implementation that exploits a divide-and-conquer approach based on a thread-pool, which does not deteriorate the original algorithmic efficiency and it is not memory bound. We extend the algorithm to parallel many-core GPU architectures adopting the CUDA programming framework, and we show how to handle the heavily workload-unbalance and the massive data dependency. Then, we suggest new heuristics that reorder the adjacency matrix, deal with "dead-ends" and randomize the search with automatic restarts, achieving significant improvements on specific cases. Finally, we propose a portfolio approach, which integrates all the different local search algorithms as component tools. Such portfolio, rather than choosing the best tool for a given instance up-front, takes the decision on-line. The proposed approach drastically limits memory bandwidth constraints and avoids other typical portfolio fragilities as CPU and GPU versions often show a complementary efficiency and run on separated platforms. Experimental results support the claims and motivate further research to better exploit GPUs in embedded task-intensive, and multi-engine parallel applications.

Figures

Figures reproduced from arXiv: 1908.06418 by the authors.

Figure 1
Figure 1. FIGURE 1: An undirected graph with induced and non [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. FIGURE 2: Given the graphs [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 3
Figure 3. FIGURE 3: A running example. The graphs [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figures from the paper (9 more)
Figure 4
Figure 4. Figure 4: FIGURE 4: Partitioning the McSplit function to parallelize [PITH_FULL_IMAGE:figures/full_fig_p003_4.png]
Figure 5
Figure 5. Figure 5: FIGURE 5: Number of recursions (a) and wall-clock times [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]
Figure 6
Figure 6. Figure 6: FIGURE 6: Cumulative number of instances (y axis) solved [PITH_FULL_IMAGE:figures/full_fig_p010_6.png]
Figure 7
Figure 7. Figure 7: FIGURE 7: Cumulative number of instances (y-axis) solved [PITH_FULL_IMAGE:figures/full_fig_p010_7.png]
Figure 8
Figure 8. Figure 8: FIGURE 8: Cumulative number of instances solved in a [PITH_FULL_IMAGE:figures/full_fig_p011_8.png]
Figure 9
Figure 9. Figure 9: FIGURE 9: The chart represents all main reasons forcing the [PITH_FULL_IMAGE:figures/full_fig_p011_9.png]
Figure 10
Figure 10. Figure 10: FIGURE 10: Extract from the profiling analysis executed by [PITH_FULL_IMAGE:figures/full_fig_p012_10.png]
Figure 11
Figure 11. Figure 11: FIGURE 11: Running times for different heuristics (reported on the y-axis) implemented within the sequential version (reported [PITH_FULL_IMAGE:figures/full_fig_p013_11.png]
Figure 12
Figure 12. Figure 12: FIGURE 12: The most efficient sequential and parallel [PITH_FULL_IMAGE:figures/full_fig_p013_12.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

30 extracted references · 30 canonical work pages

  1. [1]

    Subgraph isomorphism, matching relational structures and maximal cliques,

    H. G. Barrow and R. M. Burstall, “Subgraph isomorphism, matching relational structures and maximal cliques,” Inf. Process. Lett., vol. 4, no. 4, pp. 83–84, 1976

  2. [2]

    Finding all cliques of an undirected graph (algorithm 457),

    C. Bron and J. Kerbosch, “Finding all cliques of an undirected graph (algorithm 457),” Commun. ACM, vol. 16, no. 9, pp. 575–576, 1973

  3. [3]

    A partitioning algorithm for maximum common subgraph problems,

    C. McCreesh, P. Prosser, and J. Trimble, “A partitioning algorithm for maximum common subgraph problems,” in Proceedings of the 26th International Joint Conference on Artificial Intelligence, ser. IJCAI’17. AAAI Press, 2017, pp. 712–719. [Online]. Available: http://dl.acm.org/citation.cfm?id=3171642.3171744

  4. [4]

    The SAT Competition Web Page,

    “The SAT Competition Web Page,” http://www.satcompetition.org/, ac- cessed: 2014-12-01

  5. [5]

    The SMT Competition Web Page,

    “The SMT Competition Web Page,” http://www.smtcomp.org/, accessed: 2014-12-01

  6. [6]

    Portfolios of subgraph iso- morphism algorithms,

    L. Kotthoff, C. McCreesh, and C. Solnon, “Portfolios of subgraph iso- morphism algorithms,” in Learning and Intelligent Optimization, P. Festa, M. Sellmann, and J. Vanschoren, Eds. Cham: Springer International Publishing, 2016, pp. 107–122

  7. [7]

    A large database of graphs and its use for benchmarking graph isomorphism algorithms,

    M. De Santo, P. Foggia, C. Sansone, and M. Vento, “A large database of graphs and its use for benchmarking graph isomorphism algorithms,” Pattern Recogn. Lett., vol. 24, no. 8, p. 1067â ˘A¸ S1079, May 2003. [Online]. Available: http://dx.doi.org/10.1016/S0167-8655(02)00253-2

  8. [8]

    A database of graphs for iso- morphism and sub-graph isomorphism benchmarking,

    P. Foggia, C. Sansone, and M. Vento, “A database of graphs for iso- morphism and sub-graph isomorphism benchmarking,” in -, 2001, p. 176â ˘A¸ S187

Show all 30 references
  1. [9]

    A comparison of algorithms for maximum common subgraph on randomly connected graphs,

    H. Bunke, P. Foggia, C. Guidobaldi, C. Sansone, and M. Vento, “A comparison of algorithms for maximum common subgraph on randomly connected graphs,” in Joint IAPR International Workshops on Statistical Techniques in Pattern Recognition (SPR) and Structural and Syntactic Patter...

  2. [10]

    Challenging complexity of maximum common subgraph detection algorithms: A performance analysis of three algorithms on a wide database of graphs

    D. Conte, P. Foggia, and M. Vento, “Challenging complexity of maximum common subgraph detection algorithms: A performance analysis of three algorithms on a wide database of graphs.” J. Graph Algorithms Appl., vol. 11, no. 1, pp. 99–143, 2007

  3. [11]

    Finding maximum common connected sub- graphs using clique detection or constraint satisfaction algorithms,

    P. Vismara and B. Valery, “Finding maximum common connected sub- graphs using clique detection or constraint satisfaction algorithms,” in Modelling, Computation and Optimization in Information Systems and Management Sciences. Springer, 2008, pp. 358–368

  4. [12]

    Searching for a maximum common induced subgraph by decomposing the compatibility graph,

    M. Minot and S. N. Ndiaye, “Searching for a maximum common induced subgraph by decomposing the compatibility graph,” in en. In: Bridging the Gap Between Theory and Practice in Constraint Solvers, CP2014- Workshop, 2014, pp. 1–17. 12 VOLUME 4, 2016 Author et al.: Preparation of...

  5. [13]

    Approximating the maximum common subgraph isomorphism problem with a weighted graph,

    A. C.-L. Chen, A. Elhajj, S. Gao, A. Sarhan, S. Afra, A. Kassem, and R. Alhajj, “Approximating the maximum common subgraph isomorphism problem with a weighted graph,” Knowledge-Based Systems, vol. 85, pp. 265–276, 2015

  6. [14]

    Graph clustering using the weighted minimum common supergraph,

    H. Bunke, P. Foggia, C. Guidobaldi, and M. Vento, “Graph clustering using the weighted minimum common supergraph,” in Proceedings of the 4th IAPR International Conference on Graph Based Representations in Pattern Recognition, ser. GbRPR’03. Berlin, Heidelberg: Springer- Verlag...

  7. [15]

    A measure of similarity between graph vertices: Applications to synonym extraction and web searching,

    V . Blondel, A. Gajardo, M. Heymans, P. Senellart, and P. Van Dooren, “A measure of similarity between graph vertices: Applications to synonym extraction and web searching,” SIAM Review, vol. 46, no. 4, pp. 647–666,

  8. [16]

    Graph similarity and matching,

    L. A. Zager, “Graph similarity and matching,” Ph.D. dissertation, Massachussetts Institute of Technology, USA, 2005. [Online]. Available: http://hdl.handle.net/1721.1/34119

  9. [17]

    Mcsplit implementations,

    J. Trimble, “Mcsplit implementations,” https://github.com/ciaranm/ cpaior2018-parallel-mcs-paper/tree/master/james-cpp-parallel, 2017

  10. [18]

    Solving hard subgraph problems in parallel,

    C. McCreesh, “Solving hard subgraph problems in parallel,” Ph.D. disser- tation, University of Glasgow, 2017

  11. [19]

    Observations from parallelising three maximum common (connected) subgraph algorithms,

    R. Hoffmann, C. Mccreesh, S. N. Ndiaye, P. Prosser, C. Reilly, C. Solnon, and J. Trimble, “Observations from parallelising three maximum common (connected) subgraph algorithms,” in International Conference on the Inte- gration of Constraint Programming, Artificial Intelligence,...

  12. [20]

    Hardware Model Checking Competition 2014: An Analysis and Comparison of Model Checkers and Benchmarks,

    G. Cabodi, C. Loiacono, M. Palena, P. Pasini, D. Patti, S. Quer, D. Ven- draminetto, A. Biere, and K. Heljanko, “Hardware Model Checking Competition 2014: An Analysis and Comparison of Model Checkers and Benchmarks,” vol. 9, pp. 135–172, jun 2016

  13. [21]

    Experiments with mas- sively parallel constraint solving,

    L. Bordeaux, Y . Hamadi, and H. Samulowitz, “Experiments with mas- sively parallel constraint solving,” in IJCAI, 2003

  14. [22]

    SATzilla: Portfolio- based Algorithm Selection for SAT,

    L. Xu, F. Hutter, H. H. Hoos, and L. Leyton-Brown, “SATzilla: Portfolio- based Algorithm Selection for SAT,” Journal of Artificial Intelligence Res., vol. 32, no. 1, pp. 565–606, 2008

  15. [23]

    A self-adaptive multi-engine solver for quantified boolean formulas,

    L. Pulina and A. Tacchella, “A self-adaptive multi-engine solver for quantified boolean formulas,” Constraints, vol. 14, no. 1, pp. 80–116, Mar

  16. [24]

    Manysat: a parallel sat solver,

    Y . Hamadi and L. Sais, “Manysat: a parallel sat solver,” JOURNAL ON SATISFIABILITY , BOOLEAN MODELING AND COMPUTATION (JSAT), vol. 6, 2009

  17. [25]

    Clique and constraint models for maximum common (connected) subgraph prob- lems,

    C. McCreesh, S. N. Ndiaye, P. Prosser, and C. Solnon, “Clique and constraint models for maximum common (connected) subgraph prob- lems,” in International Conference on Principles and Practice of Constraint Programming. Springer, 2016, pp. 350–368

  18. [26]

    Between subgraph isomor- phism and maximum common subgraph,

    R. Hoffmann, C. McCreesh, and C. Reilly, “Between subgraph isomor- phism and maximum common subgraph,” in Thirty-First AAAI Confer- ence on Artificial Intelligence, feb 2017, p. 3907â ˘A¸ S3914. VOLUME 4, 2016 13 Author et al.: Preparation of Papers for IEEE TRANSACTIONS and JOURNALS

  19. [27]

    The partitioned preassigned pivot proce- dure (p4),

    S. Hellerman and D. C. Rarick, “The partitioned preassigned pivot proce- dure (p4),” Sparse Matrices and Their Applications, vol. 67-76, 01 1972

  20. [28]

    Boosting combinatorial search through randomization,

    C. P. Gomes, B. Selman, and H. Kautz, “Boosting combinatorial search through randomization,” in Fifteenth National/Tenth Conference on Artificial Intelligence/Innovative Applications of Artificial Intelligence, ser. AAAI ’98/IAAI ’98. Menlo Park, CA, USA: American Association fo...

  21. [2004]

    Available: https://doi.org/10.1137/S0036144502415960

    [Online]. Available: https://doi.org/10.1137/S0036144502415960

  22. [2009]

    Available: https://doi.org/10.1007/s10601-008-9051-2

    [Online]. Available: https://doi.org/10.1007/s10601-008-9051-2

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.