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 qsharpqdk migration 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 rotationCount in 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/operation split 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.