Upload article_en.md with huggingface_hub
Browse files- article_en.md +77 -0
article_en.md
ADDED
|
@@ -0,0 +1,77 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
---
|
| 2 |
+
title: "FINAL-Bench Quantum: An Open, Neutral Benchmark for Quantum-Computing Methods"
|
| 3 |
+
thumbnail:
|
| 4 |
+
authors:
|
| 5 |
+
- user: SeaWolf-AI
|
| 6 |
+
tags: [quantum, quantum-error-correction, benchmark, qec, vqe, qram]
|
| 7 |
+
---
|
| 8 |
+
|
| 9 |
+
# FINAL-Bench Quantum: An Open, Neutral Benchmark for Quantum-Computing Methods
|
| 10 |
+
|
| 11 |
+
Quantum-computing results are remarkably hard to compare. The same "logical error rate (LER)" or
|
| 12 |
+
"query fidelity" can mean entirely different things depending on the code, the noise model, the
|
| 13 |
+
hardware, and how many shots were taken. **FINAL-Bench Quantum** is our attempt to bring *one fair
|
| 14 |
+
yardstick* to that confusion: a suite where methods compete in five events under **identical,
|
| 15 |
+
published protocols**, and where every number is clearly labeled as either *measured here* or
|
| 16 |
+
*quoted from a source*.
|
| 17 |
+
|
| 18 |
+
🔗 **Leaderboard:** `huggingface.co/spaces/FINAL-Bench/quantum-bench-leaderboard`
|
| 19 |
+
|
| 20 |
+
## The core rule — two tracks
|
| 21 |
+
|
| 22 |
+
- **Track A (Verified).** Methods are *measured here* on one frozen, public test set and reported
|
| 23 |
+
with 95% confidence intervals. These numbers **are** directly comparable.
|
| 24 |
+
- **Track B (Reported).** Numbers *quoted* from each paper or announcement. Codes, noise models,
|
| 25 |
+
and hardware differ, so they are **not** directly comparable — and we say so plainly.
|
| 26 |
+
|
| 27 |
+
Two principles hold throughout:
|
| 28 |
+
|
| 29 |
+
1. **No quantum-advantage claims.**
|
| 30 |
+
2. **A simulation is labeled a simulation; real hardware is named with its chip.** When two results
|
| 31 |
+
fall within each other's confidence intervals, we call it a **statistical tie** rather than
|
| 32 |
+
crowning a winner.
|
| 33 |
+
|
| 34 |
+
## The five events
|
| 35 |
+
|
| 36 |
+
| Event | What it measures | One-line analogy |
|
| 37 |
+
|---|---|---|
|
| 38 |
+
| ① **QEC Decoder** | logical error rate on a rotated surface code (Stim, circuit noise) | accuracy of a quantum "spell-checker" |
|
| 39 |
+
| ② **Optimization** | Max-Cut quality (cut found / optimum) | finding the best answer among astronomically many |
|
| 40 |
+
| ③ **VQE** | molecular ground-state energy vs the exact solution | quantum energy calculation for chemistry/drugs |
|
| 41 |
+
| ④ **QRAM** | quantum-memory query fidelity | accuracy of a quantum "memory chip" |
|
| 42 |
+
| ⑤ **Simulation** | how large a circuit a classical method can handle | faking a quantum computer on a classical one |
|
| 43 |
+
|
| 44 |
+
Each event tab is organized as **A. verified measurements / B. real hardware (where available) /
|
| 45 |
+
C. published references**, alongside dedicated **📈 Charts** (threshold, distance-scaling, and
|
| 46 |
+
latency-vs-accuracy plots), **🏅 Medals** (participation by country), and **ℹ️ About**
|
| 47 |
+
(methodology and citation).
|
| 48 |
+
|
| 49 |
+
## How to read the tables
|
| 50 |
+
|
| 51 |
+
- **Flag** = a method's / team's origin; **By** = its authors (e.g., Tesseract = Google Quantum AI,
|
| 52 |
+
PyMatching = O. Higgott).
|
| 53 |
+
- **✓ VERIFIED** = measured on this benchmark. **REPORTED** = quoted from a source.
|
| 54 |
+
- The **±value** next to a number is its 95% confidence interval. Overlapping intervals mean a tie.
|
| 55 |
+
- The **latency** column matters as much as accuracy — a decoder that is "accurate but slow" can be
|
| 56 |
+
useless for real-time error correction, where decoding must keep pace with the QPU cycle.
|
| 57 |
+
|
| 58 |
+
## How to submit
|
| 59 |
+
|
| 60 |
+
The **📤 Submit** tab takes a method name, links (GitHub / Hugging Face), an email, and an optional
|
| 61 |
+
results file. Submissions are **stored privately**, reproduced under the event's fixed protocol, and
|
| 62 |
+
the submitter is emailed about inclusion. Listed entries appear with the same origin and author
|
| 63 |
+
labels as everyone else.
|
| 64 |
+
|
| 65 |
+
## Why neutrality is the whole point
|
| 66 |
+
|
| 67 |
+
A leaderboard is only useful if you can trust it. So FINAL-Bench Quantum is built on a discipline:
|
| 68 |
+
**include strong competitors even when they beat the host's own entries, quote sources faithfully,
|
| 69 |
+
and never round a simulation up into a hardware claim.** Methods from Google, IBM, NVIDIA, USTC,
|
| 70 |
+
Riverlane and others sit next to a Korean entry (VIDRAFT 🇰🇷) under the *same* protocol, confidence
|
| 71 |
+
intervals, and honesty boundaries.
|
| 72 |
+
|
| 73 |
+
Quantum computing has not yet reached the fault-tolerant era — which is exactly why a shared,
|
| 74 |
+
hype-free yardstick that honestly records *what has actually been measured today* is worth building.
|
| 75 |
+
Come and compete with your own method.
|
| 76 |
+
|
| 77 |
+
*A methods paper is in preparation. Feedback and submissions are welcome.*
|