QML speedups depend on data encoding assumptions. If classical data must be loaded into quantum states, the loading cost often negates the kernel speedup. Proven advantages exist only for specific, contrived problem structures.

Problem 11 · Quantum Machine Learning Kernel Benchmark

Overview

Quantum kernel methods map classical data into high-dimensional Hilbert spaces using parameterized feature maps. This benchmark prepares a classical radial-basis-function (RBF) baseline while scaffolding a Q# project that will later host amplitude-encoded kernel evaluations and quantum feature maps. We generate synthetic datasets of increasing difficulty, estimate classical generalization, and track metrics that future quantum enhancements aim to improve.

Directory Layout

11_quantum_machine_learning/
├── estimates/                      # JSON artifacts from classical / quantum workflows
├── instances/                      # Dataset parameter sets (small/medium/large)
├── plots/                          # Generated figures from analyze.py
├── python/
│   ├── classical_baseline.py       # Kernel ridge classification baseline
│   └── analyze.py                  # Visualization of accuracy and alignment metrics
└── qsharp/
    ├── qsharp.json            # Modern QDK project file
    └── Program.qs                  # Placeholder quantum workflow

Quick Start

cd problems/11_quantum_machine_learning

# Classical baseline (writes estimates/classical_baseline.json)
python python/classical_baseline.py

# Visualize accuracy and kernel statistics
python python/analyze.py

# Quantum placeholder
 python -c "import qsharp; qsharp.init(project_root='qsharp'); print('Build OK')"
 python tooling/run_all_qsharp.py  # runs via qsharp Python package

Next Quantum Milestones

1. Feature Map Implementation – Encode classical feature vectors into amplitude or Hamiltonian embeddings within Q#.

2. Quantum Kernel Evaluation – Use swap-test style overlaps to assemble Gram matrices for downstream classifiers.

3. Hybrid Training Loop – Combine quantum kernel evaluations with classical optimizers for model selection.

4. Resource Estimation – Evaluate qubit counts and circuit depth for realistic dataset sizes and compare against classical baselines.

This scaffold keeps the classical kernel baseline reproducible while we iterate toward genuine quantum machine learning experiments. 🤖⚛️

Objective Maturity Gate

• **Current gate**: **Stage B complete** (classical baseline and Q# scaffold/build path are in place).
• **Next gate target**: **Stage C** (hardware-aware validation with uncertainty-bounded comparisons).

Stage C exit criteria for this problem:

• Execute at least one non-placeholder quantum workflow path tied to the problem objective.
• Report uncertainty-bounded comparisons between classical and quantum outputs on `small` and `medium` instances.
• Document transpilation/connectivity and backend assumptions used for reported quantum runs.
• Add calibration/noise-sensitivity evidence for the reported quantum metrics.

DiVincenzo Readiness (Stage C/D Overlay)

| Criterion | Status | Evidence / Notes |

|---|---|---|

| Scalable qubit system | partial | Problem-scoped instance baselines are in place; full hardware-scale projections are tracked as Stage C work. |

| Initialization | partial | Input/state initialization path is defined for current workflows, with backend-ready loading fidelity still to be hardened. |

| Coherence vs gate time | not-yet | Backend-calibrated coherence-vs-depth evidence is pending and required for Stage C/D promotion. |

| Universal gate set | partial | Q# scaffold/build path exists; gate-basis decomposition and transpilation evidence remain Stage C tasks. |

| Qubit-specific measurement | partial | Measurement outputs are defined for current validation flows; hardware readout characterization is pending. |

Advantage Claim Contract

• **Claim category (current)**: `theoretical`.
• **Problem class and regime**: Problem-specific challenge instances defined in this directory.
• **Fair baseline**: Problem-local classical baseline in `python/` outputs.
• **Quantum resource scaling claim**: Expected asymptotic advantage depends on algorithm family and implementation assumptions; no hardware-demonstrated speedup claim yet.
• **Data-loading and I/O assumptions**: Must be documented alongside future advantage claims.
• **Noise/error model assumptions**: Backend-specific model and calibration assumptions to be added at Stage C.
• **Confidence/uncertainty method**: To be reported using shot-based confidence intervals or equivalent statistical bounds.
• **Residual risks**: Oracle/state-preparation/transpilation overhead may dominate for near-term instance sizes.