Affiliate disclosure
Book titles on this page link to Amazon. As an Amazon Associate, DataField.Dev earns from qualifying purchases — at no additional cost to you.
Further Reading: Microsoft Q
Tagged Tier 1 (confident it exists and recommended) and Tier 2 (real and worth seeking, but verify the current version or URL).
The primary sources
- The Microsoft Quantum Development Kit documentation. The Q# language guide, the standard
library reference, and the Python interoperability pages. Note that documentation URLs and package
names have both moved recently — §15.1's
qsharp→qdkmigration is the current state, and the docs are the only reliable place to check whether it has moved again. Tier 1. - The Azure Quantum Resource Estimator documentation. What every field in the output means,
what the qubit parameter presets (
qubit_gate_ns_e3,qubit_maj_ns_e6, …) actually assume, and how to supply custom parameters. Read this before quoting any number the estimator produces — the presets encode substantial assumptions about hardware that you are implicitly endorsing. Tier 1. - The Q# code samples repository. Full implementations of Shor, Grover, chemistry simulation, and error correction, written by people who know the language. The best available answer to "what does idiomatic Q# look like." Tier 1.
- The Q# language specification. Denser than the guide and worth it if you care about why the
type system is shaped this way — particularly the treatment of functors as capabilities and the
proof obligations attached to
is Adj. Tier 2 — verify it is current.
On resource estimation
- Craig Gidney and Martin Ekerå, "How to factor 2048 bit RSA integers in 8 hours using 20 million noisy qubits" (2021), Quantum 5, 433 (arXiv:1905.09749). Case Study 1's cross-check, and the single most important paper on this question. Read it for the methodology as much as the number — and note that its figure was more than an order of magnitude below earlier estimates, entirely through better constructions rather than better hardware. The number moves. Tier 1.
- van Dam et al. / the Azure QRE team's papers on the resource estimator's models. How the estimator computes what it computes: the surface-code model, the distillation unit specifications, the error budget partition. Necessary if you intend to defend an estimate. Tier 2.
- Bravyi and Kitaev, "Universal quantum computation with ideal Clifford gates and noisy ancillas" (2005), Physical Review A 71, 022316. Magic state distillation, at the source. This is why §15.8's cliff exists, and reading it converts "T gates are expensive" from a fact you memorized into a mechanism you understand. Tier 1.
- Fowler, Mariantoni, Martinis, and Cleland, "Surface codes: Towards practical large-scale quantum computation" (2012), Physical Review A 86, 032324. The standard reference for the code whose $d^2$ scaling drives §15.8's factor-of-27 result. Long, and the first twenty pages are the ones you need. Tier 1.
- Litinski, "A Game of Surface Codes" (2019). An unusually readable treatment of surface-code layout and lattice surgery, including the space–time trade §15.8's saturation revealed. If Fowler et al. is heavy going, start here. Tier 1.
On T-count and its optimization
- Any current work on T-count optimization and Clifford+T synthesis. Given §15.8's cliff, reducing T count is the highest-leverage compiler optimization in fault-tolerant computing — a completely different objective from Chapter 10's depth-and-SWAP minimization, and worth understanding as a separate discipline. Tier 2 — active area.
- Ross and Selinger, "Optimal ancilla-free Clifford+T approximation of z-rotations" (2016). How an
arbitrary rotation becomes a sequence of Clifford+T gates, and how many T gates that costs as a
function of the precision you demand. This is what
rotationCountin the estimator's input is about. Tier 1. - Anything on the Toffoli's 7-T decomposition and its variants. §15.8's project checkpoint asserts it as a test; the literature explains why 7 and when you can do better with measurement and feedforward. Tier 2.
On the language design argument
- Svore et al., "Q#: Enabling Scalable Quantum Computing and Development with a High-level DSL"
(2018). The design paper. Read it for the reasoning behind the
function/operationsplit and the functor system — the arguments are software-engineering arguments, and they are made explicitly. Tier 1. - Any well-argued treatment of static versus dynamic typing. Case Study 2's scorecard is a domain-specific instance of a decades-old debate, and the general literature is better than anything quantum-specific. The conclusion transfers: types catch errors of form cheaply and permanently, and the expensive bugs are elsewhere. Tier 2.
Forward references
- Chapter 23 — where Case Study 1's logical counts come from, derived rather than asserted.
- Chapter 25 — error correction in code, which is what all those physical qubits are doing.
- Chapter 38 — the practical consequence of Case Study 1: post-quantum cryptography, and why the migration deadline precedes the machine.
- Appendix E — Q# alongside the other four frameworks, call by call.
Where to go next. If one thing: Gidney and Ekerå. It is the model of how to answer a resource question honestly — explicit assumptions, a construction you can check, and a number that moved by an order of magnitude when the construction improved.
If two: add Bravyi and Kitaev on magic state distillation, because it turns §15.8's cliff from a measurement into an explanation.
Then Chapter 16 — PennyLane, which takes the opposite position from Q# on nearly everything, and makes the gradient rather than the measurement the primary output.