Pith. sign in

REVIEW 3 major objections 6 minor 1 cited by

Identifying Flaky Tests in Quantum Code: A Machine Learning Approach

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

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Tree-based ML detects flaky quantum tests with F1 0.934 on a balanced dataset and F1 0.886 on imbalanced data.

desk verdict A useful dataset wrapped in an ML evaluation whose headline numbers are not trustworthy: the labels are keyword-derived and the thresholds are tuned on the test folds. read the letter →

arxiv 2502.04471 v1 pith:AGXGRBTK submitted 2025-02-06 cs.SE cs.LG

Khushdeep Kaur , Dongchan Kim , Ainaz Jamshidi , Lei Zhang This is my paper · ORCID
classification cs.SEcs.LG
keywords quantumflakytestsmachinelearningtestdetectionsoftwaretestingXGBoostdecisiontreebag-of-wordsimbalanceddata
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 a machine learning classifier operating on the raw text of Python test files can automatically flag quantum-software tests that are likely to be flaky. Using a balanced dataset of 45 flaky and 45 non-flaky files, the authors report that extreme gradient boosting (XGB) achieves an F1 score of 0.934 and a Matthews Correlation Coefficient of 0.877, outperforming decision trees, random forests, k-nearest neighbors, and support vector machines. On an imbalanced 1:5 dataset, they report that a decision tree with threshold tuning reaches F1 0.886 and MCC 0.877. The paper also contributes an expanded dataset of 243 non-flaky Python test files, intended to support further research on quantum flakiness. The central caveat is that the flaky/non-flaky labels come from a keyword search of issue reports and pull requests, so the classifiers may be learning the distinction between keyword-containing and keyword-free files rather than between genuinely flaky and stable tests.

What carries the argument

The central machinery is a bag-of-words document-term matrix of Python test files: each file becomes a count vector of its word tokens, with stop words deliberately kept to preserve syntax. For k-nearest neighbors and support vector machines, principal component analysis reduces this high-dimensional space before classification. To handle imbalance, the authors use SMOTE to synthesize minority-class samples and threshold tuning to shift the decision boundary. The load-bearing component, however, is the label construction from the authors' prior keyword-search study [19]: a file is 'flaky' if it came from an issue report or pull request matching one of ten terms such as 'flaky' or 'intermit', and 'non-flaky' if it came from a closed report without those terms.

What would settle it

Rerun the 45 keyword-flagged flaky test files many times (e.g., 100 executions each) in the same environments and compare their pass/fail consistency; if the majority of them consistently pass or fail, the keyword-based ground truth does not reflect flakiness, and the reported F1/MCC scores would not transfer to verified flaky tests.

Watch

Extended reading notes

Core claim

The authors establish that simple bag-of-words text features from Python source files carry enough signal for tree-based classifiers to separate their keyword-derived flaky test files from non-flaky ones. In five-fold stratified cross-validation on the balanced dataset, XGB reaches F1 0.934 and MCC 0.877, and on the imbalanced dataset the decision tree with threshold tuning reaches F1 0.886 and MCC 0.877. The models that do best are the tree-based ones, with XGB and DT consistently outperforming RF, KNN, and SVM across settings. The authors interpret this as evidence that ML-based detection of quantum flaky tests is feasible without rerunning tests, and that SMOTE and threshold tuning are useful for handling class imbalance, especially for XGB.

Load-bearing premise

The flaky/non-flaky labels come from a keyword search of issue reports and pull requests, so a file is 'flaky' only because it contains one of ten words, and 'non-flaky' only because it does not; if that word-based label does not match real flaky behavior, the classifiers' high scores do not measure flakiness detection.

Editorial extensions

If this is right

  • A text-only classifier can flag likely quantum flaky tests without executing them, saving the cost of repeated reruns.
  • Tree-based models, specifically XGB and DT, are the recommended classifiers for this task, with DT the better choice under class imbalance with threshold tuning.
  • The expanded dataset of 243 non-flaky Python files provides a benchmark for future studies of quantum test flakiness.
  • SMOTE and threshold tuning materially improve XGB's MCC on imbalanced data (from 0.441 to 0.877), showing these techniques compensate for minority-class under-detection.

Reading between the lines

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

  • Because the labels are defined by keyword presence, the high F1 scores may partly reflect the model learning the keyword vocabulary; an evaluation where flakiness is confirmed by repeated test executions would show whether the approach measures actual flaky behavior.
  • The same bag-of-words pipeline could be tested on probabilistic programs in classical languages to see whether the finding generalizes beyond quantum-specific repositories.
  • Ablation tests that mask the ten flakiness keywords from the files would reveal how much of the classifier's signal is purely lexical rather than syntactic or structural.
Share X Bluesky LinkedIn Reddit HN

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 proposes a machine learning pipeline to detect flaky tests in quantum software. The authors build on their prior keyword-based study [19], extend the dataset with non-flaky Python files, vectorize the files with bag-of-words, and evaluate XGB, decision tree, random forest, KNN, and SVM classifiers on balanced and imbalanced (1:5) datasets. They report that XGB performs best on the balanced dataset (F1 0.934, MCC 0.877) and that a decision tree with threshold tuning performs best on the imbalanced dataset (F1 0.886, MCC 0.877). The paper also describes SMOTE, threshold tuning, and a hybrid configuration, and it releases data and code on Zenodo.

Significance. If the reported results were valid, this would be a timely contribution to quantum software testing: it would extend the scarce empirical data on quantum flakiness and show that lightweight text-based classifiers can identify flaky tests without rerunning them. The public dataset and code are concrete assets. However, the central evaluation is compromised by two load-bearing issues: the ground-truth labels are generated by a keyword filter, and the classifier features are word counts of the same text; and the decision thresholds for the imbalanced scenario appear to be selected using the test-fold labels. As a result, the reported F1/MCC values do not currently establish that the models detect flakiness, rather than reproducing the keyword-selection rule. The contribution is therefore conditional on substantial revalidation.

major comments (3)
  1. [II-A and II-B] The ground-truth labels are inherited from a 10-keyword search in the authors' prior study [19], and the non-flaky class is defined only as the absence of those keywords (Section II-A). The features are bag-of-words counts of the same Python files (Section II-B), so the model can effectively learn to distinguish files that contain words like "flaky" or "occasional" from files that do not. The reported F1 of 0.934 and MCC of 0.877 therefore measure separation between keyword-selected and keyword-excluded files, not between genuinely flaky and non-flaky tests. To support the paper's central claim, the authors need an independent ground truth, for example, by rerunning the tests to confirm inconsistent behavior or by manually validating flakiness without using the 10 terms, and they should verify that the classifier does not rely primarily on the keyword features themselves.
  2. [IV-A and VI-C] Section IV-A states that "thresholds are tuned during testing to make predictions," and Section VI-C says "we choose the thresholds giving the best F1 scores." If, as written, the threshold is selected on each test fold using the true fold labels, then the imbalanced "Threshold only" and "Hybrid" results in Table II are not valid out-of-sample estimates. The headline imbalanced result for the decision tree (F1 0.886, MCC 0.877) could be an artifact of test-set threshold selection, and the comparison against vanilla models using the default 0.5 threshold is unfair. The authors should either confirm that thresholds were chosen only from training-fold data (e.g., by cross-validation within each training fold) or rerun the analysis with a nested threshold-selection procedure and report both the selected thresholds and the resulting test-fold metrics.
  3. [II-A] The data-preprocessing section reports that environment-related flaky files were removed because they "decreas[ed] the performance across all models." This is an outcome-based exclusion rule: files are dropped because including them worsens the evaluation metrics, which can inflate the reported performance and undermine any claim that the models generalize to a realistic population of flaky tests. The removal should be justified by an independent, pre-specified criterion (e.g., a definition of environment-related flakiness), and the authors should report the performance on the full set of 99 files or on the 45-file subset before this exclusion to assess the sensitivity of the results.
minor comments (6)
  1. [III-C] The sentence "In most cases, flaky classes get incorrectly labeled as non-flaky, leading to more false positives" appears to describe false negatives, not false positives; please correct this wording.
  2. [VI, Table II] The caption says "The best results among all models are highlighted with underscores," but the table underscores many entries across different configurations; please clarify whether the highlights indicate the best result within each configuration block, the overall best, or something else.
  3. [II-A] Please clarify the mapping between the 46 flaky tests and the 99 extracted files, and then the reduction to 45 Python files: state explicitly how a file is assigned the flaky label when a test spans multiple files.
  4. [II-A] The non-flaky files are sampled only from the qiskit repository, while the flaky files come from six repositories; this repository mismatch is a potential confounder and should be discussed or mitigated by matching the sampling repository.
  5. [III-A and V] Please clarify whether the grid search for hyperparameters and PCA components is performed inside each training fold or on the pooled data; if model selection uses the test folds indirectly, the reported standard deviations are optimistic.
  6. [X] The Zenodo link is appreciated; please include a version identifier and access date so the exact artifact snapshot can be recovered.

Circularity Check

2 steps flagged · score 7.0 of 10

Imbalanced DT win is a test-set threshold fit, and the ground-truth labels are the authors' own keyword-search output; the reported scores do not establish flaky-test detection.

  1. self citation load bearing [Section II-A (Data Collection) and Section II-B (Vectorization)]
    "Our dataset is built upon our previous empirical study [19]. They identify 46 unique flaky tests from 12 quantum software repositories using a keyword search of 10 terms related to flakiness... Second, if a sampled IR or PR matches any of the 10 flaky keywords defined in [19], it is eliminated to ensure there are no flaky tests."

    The target label 'flaky' is the output of a 10-keyword filter applied by the same group's prior study, and 'non-flaky' is defined as the absence of those keywords. The classifier is trained on bag-of-words counts of Python files extracted from those same IRs/PRs, so the supervised task is to predict the keyword-filter output. High F1/MCC therefore show separability of keyword-selected versus keyword-excluded files, not verified flakiness. The paper motivates ML as replacing 'keyword-based methods,' but its ground truth is the keyword-based method itself.

  2. fitted input called prediction [Section IV-A (Model Training) and Section VI-C (Threshold Tuning Models), Table II]
    "While SMOTE is applied during the training part to augment the data, thresholds are tuned during testing to make predictions. ... we tune the decision threshold of our models ... and we choose the thresholds giving the best F1 scores."

    Threshold tuning is a parameter-fitting step; performing it 'during testing' and choosing 'the thresholds giving the best F1 scores' means the test-fold true labels are used to set the decision boundary before the fold's F1/MCC are computed. The imbalanced headline result (DT with threshold tuning, F1 0.886, MCC 0.877 in Table II) is therefore an in-sample fit, not a prediction. Comparing it with vanilla models at the default 0.5 threshold is an unfair horse race, and the claim that DT outperforms other models on the imbalanced dataset is unsupported by the reported numbers.

full rationale

The core derivation has two circular or self-referential links. First, the ground-truth labels are inherited from the authors' own prior keyword-search study [19]: 'flaky' means the file came from an IR/PR matching one of 10 keywords, and 'non-flaky' means no keyword matched. The bag-of-words features are computed from Python files drawn from those same artifacts, so the supervised task is to predict the keyword-filter output; high scores show separability of keyword-selected versus keyword-excluded files, not verified flakiness. This is load-bearing self-citation because the paper presents ML as an alternative to keyword-matching while using keyword-matching labels as its only supervision. Second, the imbalanced evaluation is compromised by test-set threshold selection: 'thresholds are tuned during testing' and thresholds are chosen to maximize F1, so the DT threshold-tuning result reported as the best imbalanced model is fitted to the test folds. This alone invalidates the headline imbalanced comparison. Section II-A also describes removing environment-related flaky files after observing they 'decrease the performance across all models,' which is outcome-based data selection; this is a validity threat rather than a formal circular step, but it further inflates the reported scores. The balanced-dataset comparison and the SMOTE-only/SMOTE-hybrid results do not share the threshold-tuning leakage, but they still inherit the keyword-defined labels. Overall the central claims reduce, in part, to predicting a self-cited keyword-search label and to test-set-fitted thresholds, so a score of 7 is appropriate.

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

The central claim rests on two inherited items rather than established facts: flakiness labels from keyword search in [19] and non-flaky labels defined by keyword absence. Because the features are word counts of the same text, the evaluated task is separation of keyword-selected files. All free parameters are standard ML hyperparameters tuned by grid search on a small dataset. No new physical or conceptual entities are introduced.

free parameters (6)
  • XGB hyperparameters = learning_rate=0.5, max_depth=5, n_estimators=100 (SMOTE: 0.3, depth 3, 200 estimators)
    Selected by grid search optimizing F1, stated in Section V. Standard model hyperparameters fitted to this small dataset.
  • DT hyperparameters = entropy, max_depth=10, min_samples_leaf=2, min_samples_split=10 (SMOTE: Gini, leaf=2)
    Selected by grid search in Section V as part of the model comparison.
  • RF hyperparameters = n_estimators=200, entropy, max_depth=10, min_samples_leaf=2, min_samples_split=5 (SMOTE: 100 estimators)
    Grid-searched in Section V; part of the compared configurations.
  • PCA component counts for KNN and SVM = KNN 150 (SMOTE 200); SVM 220 (SMOTE 180)
    Chosen by grid search to optimize F1 in Section V; PCA is applied only to the non-tree models.
  • Classification decision threshold = varied 0.1 to 0.9, best-F1 threshold chosen
    Threshold tuning in Sections III-C and VI-C; the paper states thresholds are tuned during testing, which risks fitting this parameter to test-fold outcomes.
  • SMOTE number of neighbors = 5 (default)
    Stated in Section III-B as the default value; affects synthetic sample generation in the imbalanced setup.
assumptions (4)
  • domain assumption The 46 keyword-identified flaky tests from [19] are valid flakiness ground truth.
    Section II-A reuses labels from the prior keyword search without independent verification such as reruns or root-cause confirmation.
  • domain assumption Closed IRs/PRs that do not match the 10 keywords are non-flaky.
    Section II-A defines non-flaky files by keyword absence, but absence of the words does not prove a test is not flaky.
  • domain assumption Files extracted from a flaky issue report or pull request inherit the flaky label.
    Section II-A maps 46 tests to 99 files and then 45 Python files; the link from report-level flakiness to file-level labels is assumed without validation.
  • domain assumption Bag-of-words with stop words retained captures flakiness-relevant signal in code.
    Section II-B drops syntax, control flow, and API-call structure, keeping only word counts; this representation may miss the semantic causes of flakiness.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Identifying Flaky Tests in Quantum Code: A Machine Learning Approach." pith.science (2026). https://pith.science/paper/AGXGRBTK

@misc{pith2026250204471,
  author       = {Pith},
  title        = {Pith review of: Identifying Flaky Tests in Quantum Code: A Machine Learning Approach},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/AGXGRBTK}},
  note         = {Machine review of arXiv:2502.04471}
}
read the original abstract

Testing and debugging quantum software pose significant challenges due to the inherent complexities of quantum mechanics, such as superposition and entanglement. One challenge is indeterminacy, a fundamental characteristic of quantum systems, which increases the likelihood of flaky tests in quantum programs. To the best of our knowledge, there is a lack of comprehensive studies on quantum flakiness in the existing literature. In this paper, we present a novel machine learning platform that leverages multiple machine learning models to automatically detect flaky tests in quantum programs. Our evaluation shows that the extreme gradient boosting and decision tree-based models outperform other models (i.e., random forest, k-nearest neighbors, and support vector machine), achieving the highest F1 score and Matthews Correlation Coefficient in a balanced dataset and an imbalanced dataset, respectively. Furthermore, we expand the currently limited dataset for researchers interested in quantum flaky tests. In the future, we plan to explore the development of unsupervised learning techniques to detect and classify quantum flaky tests more effectively. These advancements aim to improve the reliability and robustness of quantum software testing.

Figures

Figures reproduced from arXiv: 2502.04471 by the authors.

Figure 1
Figure 1. A high-level overview of our employed pipeline for flaky detection. [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Detecting Flakiness in Quantum Software: A Dynamic Testing Approach

    cs.SE 2025-12 conditional novelty 7.0 of 10

    Across 23 Qiskit Terra releases, 290 tests were flaky in 10,000 runs each; most fail rarely (about 1e-4 to 1e-3), so typical CI rerun budgets miss them.

Reference graph

Works this paper leans on

33 extracted references · 27 canonical work pages · cited by 1 Pith paper

  1. [19]

    Identifying flakiness in quantum programs,

    L. Zhang, M. Radnejad, and A. Miranskyy, “Identifying flakiness in quantum programs,” in Proceedings of the 2023 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM). IEEE, 2023, pp. 1–7

    work page 2023

  2. [1]

    Taming Google-scale continuous testing,

    A. Memon, Z. Gao, B. Nguyen, S. Dhanda, E. Nickell, R. Siem- borski, and J. Micco, “Taming Google-scale continuous testing,” in Proceedings of the 2017 IEEE/ACM 39th International Confer- ence on Software Engineering: Software Engineering in Practice Track (ICSE-SEIP). IEEE, 2017, pp. 233–242

    work page 2017

  3. [2]

    Root causing flaky tests in a large-scale industrial setting,

    W. Lam, P. Godefroid, S. Nath, A. Santhiar, and S. Thum- malapenta, “Root causing flaky tests in a large-scale industrial setting,” in Proceedings of the 28th ACM SIGSOFT International Symposium on Software Testing and Analysis, 2019, pp. 101–111

    work page 2019

  4. [3]

    A survey on how test flakiness affects developers and what support they need to address it,

    M. Gruber and G. Fraser, “A survey on how test flakiness affects developers and what support they need to address it,” in Proceedings of 2022 IEEE Conference on Software Testing, Verification and Validation (ICST). IEEE, 2022, pp. 82–92

    work page 2022

  5. [4]

    A sur- vey of flaky tests,

    O. Parry, G. M. Kapfhammer, M. Hilton, and P. McMinn, “A sur- vey of flaky tests,” ACM Transactions on Software Engineering and Methodology (TOSEM) , vol. 31, no. 1, pp. 1–74, 2021

    work page 2021

  6. [5]

    An empirical anal- ysis of flaky tests,

    Q. Luo, F. Hariri, L. Eloussi, and D. Marinov, “An empirical anal- ysis of flaky tests,” in Proceedings of the 22nd ACM SIGSOFT international symposium on foundations of software engineering , 2014, pp. 643–653

    work page 2014

  7. [6]

    An empirical study of flaky tests in Python,

    M. Gruber, S. Lukasczyk, F. Kroiß, and G. Fraser, “An empirical study of flaky tests in Python,” in Proceedings of 2021 14th IEEE Conference on Software Testing, Verification and Validation (ICST). IEEE, 2021, pp. 148–158

    work page 2021

  8. [7]

    iDFlakies: A framework for detecting and partially classifying flaky tests,

    W. Lam, R. Oei, A. Shi, D. Marinov, and T. Xie, “iDFlakies: A framework for detecting and partially classifying flaky tests,” in Proceedings of 2019 12th ieee conference on software testing, validation and verification (icst) . IEEE, 2019, pp. 312–322

    work page 2019

Show all 33 references
  1. [8]

    Shake it! detecting flaky tests caused by concurrency with shaker,

    D. Silva, L. Teixeira, and M. d’Amorim, “Shake it! detecting flaky tests caused by concurrency with shaker,” in Proceedings of the 2020 IEEE International Conference on Software Mainte- nance and Evolution (ICSME) . IEEE, 2020, pp. 301–311

    2020

  2. [9]

    DeFlaker: Automatically detecting flaky tests,

    J. Bell, O. Legunsen, M. Hilton, L. Eloussi, T. Yung, and D. Marinov, “DeFlaker: Automatically detecting flaky tests,” in Proceedings of the 40th international conference on software engineering, 2018, pp. 433–444

    2018

  3. [10]

    FlakeFlagger: Predicting flakiness without rerunning tests,

    A. Alshammari, C. Morris, M. Hilton, and J. Bell, “FlakeFlagger: Predicting flakiness without rerunning tests,” in Proceedings of the 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE). IEEE, 2021, pp. 1572–1584

    2021

  4. [11]

    Know you neighbor: Fast static prediction of test flakiness,

    R. Verdecchia, E. Cruciani, B. Miranda, and A. Bertolino, “Know you neighbor: Fast static prediction of test flakiness,” IEEE Access, vol. 9, pp. 76 119–76 134, 2021

    2021

  5. [12]

    FlakyCat: Predicting flaky tests categories using few-shot learn- ing,

    A. Akli, G. Haben, S. Habchi, M. Papadakis, and Y . Le Traon, “FlakyCat: Predicting flaky tests categories using few-shot learn- ing,” in Proceedings of 2023 IEEE/ACM International Confer- ence on Automation of Software Test (AST) . IEEE, 2023, pp. 140–151

    2023

  6. [13]

    Test flakiness across programming languages,

    K. Barbosa, R. Ferreira, G. Pinto, M. d’Amorim, and B. Miranda, “Test flakiness across programming languages,” IEEE Transac- tions on Software Engineering , vol. 49, no. 4, pp. 2039–2052, 2022

    2022

  7. [14]

    A qualitative study on the sources, impacts, and mitigation strategies of flaky tests,

    S. Habchi, G. Haben, M. Papadakis, M. Cordy, and Y . Le Traon, “A qualitative study on the sources, impacts, and mitigation strategies of flaky tests,” inProceedings of 2022 IEEE Conference on Software Testing, Verification and Validation (ICST) . IEEE, 2022, pp. 244–255

    2022

  8. [15]

    Software engineering for quantum programming: How far are we?

    M. De Stefano, F. Pecorelli, D. Di Nucci, F. Palomba, and A. De Lucia, “Software engineering for quantum programming: How far are we?” Journal of Systems and Software , vol. 190, p. 111326, 2022

    2022

  9. [16]

    Quantum software engineering: Landscapes and hori- zons,

    J. Zhao, “Quantum software engineering: Landscapes and hori- zons,” arXiv preprint arXiv:2007.07047 , 2020

    2007 arXiv

  10. [17]

    Quantum computers and quantum computations,

    K. Valiev, “Quantum computers and quantum computations,” Physics-Uspekhi, vol. 48, no. 1, p. 1, 2005

    2005

  11. [18]

    Quantum entanglement,

    R. Horodecki, P. Horodecki, M. Horodecki, and K. Horodecki, “Quantum entanglement,” Reviews of modern physics , vol. 81, no. 2, pp. 865–942, 2009

    2009

  12. [20]

    XGBoost: A scalable tree boosting system,

    T. Chen and C. Guestrin, “XGBoost: A scalable tree boosting system,” in Proceedings of the 22nd ACM SIGKDD International Conference on Knowledge Discovery and Data Mining, 2016, pp. 785–794

    2016

  13. [21]

    Induction of decision trees,

    J. R. Quinlan, “Induction of decision trees,” Machine learning , vol. 1, pp. 81–106, 1986

    1986

  14. [22]

    Random forests,

    L. Breiman, “Random forests,” Machine learning , vol. 45, pp. 5–32, 2001

    2001

  15. [23]

    KNN model- based approach in classification,

    G. Guo, H. Wang, D. Bell, Y . Bi, and K. Greer, “KNN model- based approach in classification,” in Proceedings of On The Move to Meaningful Internet Systems 2003: CoopIS, DOA, and ODBASE. Springer, 2003, pp. 986–996

    2003

  16. [24]

    Support-vector networks,

    C. Cortes, “Support-vector networks,” Machine Learning, 1995

    1995

  17. [25]

    An overview of bag of words; importance, implementation, applications, and challenges,

    W. A. Qader, M. M. Ameen, and B. I. Ahmed, “An overview of bag of words; importance, implementation, applications, and challenges,” in Proceedings of 2019 international engineering conference (IEC). IEEE, 2019, pp. 200–204

    2019

  18. [26]

    An overview of principal component analysis,

    S. Karamizadeh, S. M. Abdullah, A. A. Manaf, M. Zamani, and A. Hooman, “An overview of principal component analysis,” Journal of signal and information processing , vol. 4, no. 3, pp. 173–175, 2013

    2013

  19. [27]

    A random forest guided tour,

    G. Biau and E. Scornet, “A random forest guided tour,” Test, vol. 25, pp. 197–227, 2016

    2016

  20. [28]

    Automated flakiness detection in quantum software bug reports,

    L. Zhang and A. Miranskyy, “Automated flakiness detection in quantum software bug reports,” arXiv preprint arXiv:2408.05331, 2024

    2024 arXiv

  21. [29]

    Automating quantum software maintenance: Flakiness detection and root cause analysis,

    J. Sivaloganathan, A. Jamshidi, A. Miranskyy, and L. Zhang, “Automating quantum software maintenance: Flakiness detection and root cause analysis,” arXiv preprint arXiv:2410.23578, 2024

    2024 arXiv

  22. [30]

    Smote: synthetic minority over-sampling technique,

    N. V . Chawla, K. W. Bowyer, L. O. Hall, and W. P. Kegelmeyer, “Smote: synthetic minority over-sampling technique,” Journal of artificial intelligence research, vol. 16, pp. 321–357, 2002

    2002

  23. [31]

    Wohlin, P

    C. Wohlin, P. Runeson, M. H ¨ost, M. Ohlsson, B. Regnell, and A. Wessl ´en, Experimentation in Software Engineering , ser. Computer Science. Springer Berlin Heidelberg, 2012

    2012

  24. [32]

    R. K. Yin, Case study research: Design and methods . SAGE, 2009, vol. 5

    2009

  25. [33]

    Six strategies for generalizing software engineering theories,

    R. J. Wieringa and M. Daneva, “Six strategies for generalizing software engineering theories,” Science of computer program- ming, vol. 101, pp. 136–152, 4 2015

    2015

Pith tools

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