tuneR: A Deep Dive into Hyperparameter Optimization with mixOmics

This article was originally published on Medium. Read the full version here.

The Problem

In computational biology, a poorly tuned model isn’t just an inefficiency—it is the difference between discovering a biomarker and publishing statistical noise.

mixOmics provides multivariate analysis tools for omics data, but hyperparameter tuning can become the slowest part of the workflow. With basic grid search, users choose between exhaustive evaluation time and shallow parameter coverage. Neither is a good scientific trade.

In practice, a typical block.splsda model grows quickly. With 5 components, 5 gene thresholds, and 5 miRNA thresholds, the search already has 125 combinations, each requiring cross-validation. The cost compounds before the model is even interesting.

The Solution: tuneR

tuneR narrows that search cost with two concrete choices:

1. Random search with comparable accuracy: In my benchmark harness, random search tests 50 of 125 combinations, cuts median wall time by 60.5%, and still matches the best observed accuracy on the controlled workload.
2. Reproducible benchmark artifacts: I kept raw runs, summary files, and environment metadata beside the code so the claim can be rechecked against the current code.

Quick Start

library(tuneR)
library(mixOmics)

# Load example multi-omics data
data(breast.tumors)
X_blocks <- list(
  genes = breast.tumors$gene,
  mirnas = breast.tumors$miRNA
)
Y_treatment <- breast.tumors$sample$treatment

# Grid search tuning
result_grid <- tune(
  method = "block.splsda",
  data = list(X = X_blocks, Y = Y_treatment),
  ncomp = c(1, 2, 3),
  test.keepX = list(
    genes = c(20, 50, 100),
    mirnas = c(10, 20, 30)
  ),
  search_type = "grid",
  nfolds = 5,
  stratified = TRUE
)

# View results
print(result_grid)
summary(result_grid)
plot(result_grid)

Random Search for Efficiency

result_random <- tune(
  method = "block.splsda",
  data = list(X = X_blocks, Y = Y_treatment),
  ncomp = c(1, 2, 3, 4, 5),
  test.keepX = list(
    genes = c(20, 50, 100, 150, 200),
    mirnas = c(10, 20, 30, 40, 50)
  ),
  search_type = "random",
  n_random = 50,
  nfolds = 5
)

# Compare the random-search results against the benchmark summary artifacts
plot(result_random, type = "scatter")

Search Space Complexity

The challenge in sPLS-DA tuning is the size of the parameter grid. A typical search space in tuneR is defined as follows:

# Defining a high-dimensional search space
test.keepX <- list(
  genes = seq(10, 500, by = 50),
  mirnas = seq(5, 100, by = 10),
  proteomics = seq(10, 200, by = 20)
)

# Total combinations: 10 * 10 * 10 = 1000
# With 5-fold cross-validation: 5,000 model evaluations

Benchmark Results: Grid vs. Random Search

On this benchmark, random search reaches near-identical accuracy while using fewer evaluations. That is the useful win: more of the search space can be explored before the workflow needs larger compute.

Reproduction

To verify these claims, run the mock simulation script and compare the random-search path against the grid baseline:

1. Clone the Benchmark:

   git clone https://gist.github.com/omar391/6440c8187a6b7b43a0ec4497f82b0591 tuner-bench
   cd tuner-bench

2. Execute the R Script:

   Rscript tuneR_bench.R

Key Features

• Search Strategies: Exhaustive grid search and random search
• Metrics: Accuracy and error-rate summaries alongside saved benchmark artifacts
• Computational Efficiency: Random search cuts median wall time by 60.5% on my controlled benchmark harness
• Cross-Validation: Stratified sampling with flexible fold configuration
• Visualizations: Parameter landscapes, performance distributions, and optimization paths
• Benchmark Traceability: Raw runs, summary tables, and environment metadata live alongside the code
• Extension Points: Structure for adding more mixOmics methods
• Rerunnable Validation: Controlled benchmark scripts can be rerun against the current code

Why This Matters

In computational biology, poor tuning can turn a useful model into noise. tuneR makes the tuning path explicit: define the search, run it reproducibly, and keep the benchmark artifacts close to the code.

The same pipeline design — systematic exploration, metric-driven optimization, reproducibility — transfers directly to any domain where model selection impacts operational decisions.

Source code: github.com/omar391/tuneR