mirror of
https://github.com/saymrwulf/QuantumLearning.git
synced 2026-05-14 20:58:00 +00:00
531 lines
47 KiB
Text
531 lines
47 KiB
Text
{
|
|
"cells": [
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"# Capstone Circuit Design Review\n",
|
|
"\n",
|
|
"This notebook is built as lecture notes plus a local design studio. Read the markdown carefully, then use the interactive cells to test whether your mental model is actually working.\n"
|
|
],
|
|
"id": "f0f39e5d"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"## Learning Objective\n",
|
|
"\n",
|
|
"**Primary objective:** treat circuit design as a professional review process involving alternatives, metrics, risks, and a defended final recommendation\n",
|
|
"\n",
|
|
"By the end of the notebook, you should be able to explain the central idea in plain language, modify the canonical circuit without losing track of its meaning, answer concept-check questions without guessing, and connect the notebook\u2019s local lesson to later professional design work.\n"
|
|
],
|
|
"id": "ea86e35a"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"## Why This Matters Professionally\n",
|
|
"\n",
|
|
"This notebook is the closest thing in the course to real engineering practice. A professional designer does not present a single circuit as destiny. They compare candidate designs, benchmark them, discuss risks, and justify a recommendation.\n",
|
|
"\n",
|
|
"The right way to read this notebook is therefore not \u201chow do I finish it?\u201d but \u201cwhat professional skill is this page trying to install into me?\u201d Every section, quiz, and editable lab is pointed at that question.\n"
|
|
],
|
|
"id": "68a93b7e"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"## Study Method For This Notebook\n",
|
|
"\n",
|
|
"Use the following rhythm all the way through:\n",
|
|
"\n",
|
|
"1. read the explanation before you execute the next code cell\n",
|
|
"2. state a prediction out loud or in writing\n",
|
|
"3. run the cell\n",
|
|
"4. compare the output to your prediction\n",
|
|
"5. explain any mismatch without hand-waving\n",
|
|
"\n",
|
|
"If you skip the prediction step, you lose most of the learning value. Passive recognition is much weaker than active prediction.\n"
|
|
],
|
|
"id": "5b5c8ec0"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"## Extended Lecture Notes I\n",
|
|
"\n",
|
|
"The learning objective of this notebook is not simply to let you execute a working example. The real objective is: **treat circuit design as a professional review process involving alternatives, metrics, risks, and a defended final recommendation**. That wording matters because professional growth is always about a capability, not a demo. A demo proves that one arrangement of code can run. A capability means you understand why the arrangement works, what would break it, how to modify it, and how to explain it to another engineer. When you study this notebook, do not ask only whether the final plot or diagram looks right. Ask whether you could reconstruct the same idea from memory, defend the design choices aloud, and spot a broken version of the construction if someone quietly changed one line.\n",
|
|
"\n",
|
|
"The professional relevance is direct. This notebook is the closest thing in the course to real engineering practice. A professional designer does not present a single circuit as destiny. They compare candidate designs, benchmark them, discuss risks, and justify a recommendation. That means this notebook should be read with a design mindset. A design mindset is slower than a copying mindset. You pause at each transformation, ask what role it plays, ask which other transformation could play a similar role, and ask how the diagram communicates the intention. Those habits feel inefficient at first, but they are exactly what later allows you to move from classroom-scale circuits to research or engineering-scale circuits.\n",
|
|
"\n",
|
|
"The most important reading habit in this notebook is to keep two descriptions in your head at the same time. One description is the code. The other description is the process that the code is trying to induce. The code is just the interface. The process is the actual concept. If you over-identify with the code listing, every new notebook will feel like new syntax. If you identify with the process instead, later notebooks become variations on a familiar set of design moves.\n",
|
|
"\n",
|
|
"Here is the mental stance to hold while reading: the circuit is a time-ordered argument. Each gate says, \u201cbecause of what I know about the current state, the next state should look like this.\u201d If you cannot explain that argument step by step, you have not yet turned notebook exposure into engineering understanding. That is why the notebook includes editable labs and reference tables. The point is to force a conversation between the code, the diagram, and your explanation.\n",
|
|
"\n",
|
|
"The key vocabulary for this notebook is:\n",
|
|
"\n",
|
|
"- **candidate design**: one proposed circuit family or implementation choice\n",
|
|
"- **review memo**: a structured written justification of a design decision\n",
|
|
"- **risk**: a plausible failure mode or engineering concern tied to a design choice\n",
|
|
"- **recommendation**: the defended final choice after comparing alternatives\n",
|
|
"\n",
|
|
"These terms are not decoration. Each one names a handle you need in order to reason clearly. Beginners often say vague things like \u201cthe circuit sort of does a quantum thing here.\u201d That is not good enough. Precise language reduces confusion. It lets you distinguish preparation from transformation, correlation from measurement, and implementation detail from conceptual goal. If you use precise words, you will think more precisely.\n"
|
|
],
|
|
"id": "5f965ea0"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"## Extended Lecture Notes II\n",
|
|
"\n",
|
|
"A good way to approach this notebook is to imagine that you are the reviewer of a junior engineer\u2019s circuit. You are not allowed to be impressed by the diagram merely because it contains quantum gates. You must be able to ask brutal but fair questions. Why is each step there? Which line is carrying the logical burden? What would happen if we removed or moved a gate? Which pieces are conceptually essential, and which pieces are bookkeeping? Those questions are how real design judgment develops.\n",
|
|
"\n",
|
|
"For this notebook, the most useful mental models are:\n",
|
|
"\n",
|
|
"- A good final answer is usually comparative, not absolute.\n",
|
|
"- Metrics matter, but they do not eliminate judgment.\n",
|
|
"- A review is strongest when it makes tradeoffs explicit instead of hiding them.\n",
|
|
"\n",
|
|
"Notice that these are models, not formulas. Formulas matter, but the formulas land much better when they attach to stable intuitions. A professional designer can move back and forth between intuition and formalism. The intuition says what kind of structural event is happening. The formalism says exactly how to calculate it. If you only have intuition, you become hand-wavy. If you only have formalism, you become brittle and slow. The notebook text is intentionally trying to build both at once.\n",
|
|
"\n",
|
|
"The canonical story in this notebook is: start from a design problem, create at least two candidate circuit approaches, compare them under explicit metrics, then defend the final recommendation as if writing to another engineer This story is worth reading several times because it encodes the design narrative of the example. The point is not merely that the example works. The point is that it gives you a vocabulary for talking about cause and effect inside the circuit. You should be able to retell that story while pointing alternately to the code and the diagram. That is why the next cells give you a reference table with numbered markers and an editable circuit lab whose comments use the same markers.\n",
|
|
"\n",
|
|
"Keep the following design lens in mind while you work: Ask what decision you are making, what evidence supports it, and what risks remain even after you decide. The design lens is what prevents the notebook from becoming just another gallery of tricks. Later, when you face a more complicated circuit, this lens will help you recognize that the new design is still built from a small number of recurring ideas. That recognition is one of the main signs that you are leaving the amateur stage.\n",
|
|
"\n",
|
|
"Finally, accept that slowness here is productive. If a beginner notebook feels almost embarrassingly basic, that is usually the exact place where hidden weakness lives. Engineers who rush past foundations are often the same people who later cannot explain why transpilation, noise, or verification changed the story. Slow down, narrate every move, and make your understanding explicit.\n"
|
|
],
|
|
"id": "e2973f12"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"## Extended Lecture Notes IV\n",
|
|
"\n",
|
|
"There is a difference between seeing a circuit and *owning* a circuit. Seeing means you can follow the syntax while the notebook is in front of you. Owning means you can reconstruct the design intention later, explain what would happen if one line changed, and say which parts of the design are conceptually central. The goal of this notebook is ownership. That is why the prose is intentionally repetitive in a useful way. It keeps returning to the learning objective from several angles because strong understanding usually needs multiple passes through the same idea, not one quick exposure.\n",
|
|
"\n",
|
|
"Another important professional habit is self-explanation. After you run any important cell, pause and say what the result means in relation to the notebook objective: treat circuit design as a professional review process involving alternatives, metrics, risks, and a defended final recommendation. If you cannot connect the result back to that objective, you are probably collecting observations without integrating them. Integration is the real challenge. The course is trying to make integration visible and trainable. Quizzes help because they reveal whether your language is crisp. Editable labs help because they reveal whether your understanding survives change. Reflection prompts help because they force you to produce explanations rather than merely recognize them.\n",
|
|
"\n",
|
|
"Also notice how the notebook keeps connecting local ideas to later professional roles. This is not decorative motivation. It is a memory device. When you understand how a small foundational lesson will later reappear in synthesis, transpilation, verification, or capstone review, you encode it more deeply. The present notebook becomes a seed for later concepts instead of a standalone episode.\n",
|
|
"\n",
|
|
"Finally, remember that being lost is often a signal that the transition between representations is weak. The course therefore tries to keep translating the same idea into prose, code, diagram, quiz question, and editable lab. Those translations are not redundant. They are the mechanism by which a fragile understanding becomes robust.\n"
|
|
],
|
|
"id": "1420405c"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"## Extended Lecture Notes VIII\n",
|
|
"\n",
|
|
"The phrase learning objective can sound administrative, but in a serious course it should function like a contract. The notebook says it will train a particular ability, and the notebook should then repeatedly expose that ability from different angles until it becomes visible, testable, and improvable. In this notebook the contract is: treat circuit design as a professional review process involving alternatives, metrics, risks, and a defended final recommendation. Read that sentence slowly. It contains several smaller obligations hidden inside one larger sentence. Usually those obligations include vocabulary, structural reading, state or process prediction, behavioral interpretation, and the ability to tolerate small modifications without losing the conceptual plot. If one of those obligations is missing, your understanding may feel better than it really is.\n",
|
|
"\n",
|
|
"This is why the notebook keeps returning to the same central mechanism instead of constantly introducing new examples. Variety is seductive, but repetition around a sharp objective is often more pedagogically powerful. If the same design idea can survive explanation in prose, code, diagram, quiz form, and editable lab form, then your grasp of it is becoming durable. If the idea only makes sense in one representation, you are still dependent on that representation and are not yet designing freely.\n",
|
|
"\n",
|
|
"Another way to say the same thing is this: the notebook is trying to teach you what to pay attention to. That may be the single most important beginner-to-professional transition in any technical field. Experts and amateurs often look at the same object but do not see the same burden. The amateur sees a list of steps. The expert sees the lines carrying the main causal load, the lines doing local bookkeeping, the assumptions the design depends on, and the likely places where later constraints will distort the picture. A notebook like this cannot grant expertise immediately, but it can start shaping the same habits of attention.\n",
|
|
"\n",
|
|
"When you work through the editable cells, keep asking four questions. First, which part of the circuit is the main mechanism rather than mere setup? Second, how does the diagram communicate that mechanism more clearly than raw code? Third, what result would count as evidence that your story about the mechanism is wrong? Fourth, how would the same design need to change under later hardware or noise constraints? Those questions are worth practicing now because they are the same family of questions you will use in professional design review later.\n",
|
|
"\n",
|
|
"If the notebook starts to feel repetitive, test whether the repetition is doing work. Can you now explain the objective more precisely than you could ten minutes ago? Can you point to a specific marker and state why it matters for the whole construction? Can you describe what would likely happen if that marker were altered? If the answer is yes, the repetition is succeeding. It is turning exposure into control.\n"
|
|
],
|
|
"id": "b582f08a"
|
|
},
|
|
{
|
|
"cell_type": "code",
|
|
"execution_count": null,
|
|
"metadata": {},
|
|
"outputs": [],
|
|
"source": [
|
|
"from pathlib import Path\n",
|
|
"import sys\n",
|
|
"\n",
|
|
"project_root = Path.cwd().resolve()\n",
|
|
"if project_root.name == \"notebooks\":\n",
|
|
" project_root = project_root.parent\n",
|
|
"\n",
|
|
"src_path = project_root / \"src\"\n",
|
|
"if str(src_path) not in sys.path:\n",
|
|
" sys.path.insert(0, str(src_path))\n"
|
|
],
|
|
"id": "dc758c0f"
|
|
},
|
|
{
|
|
"cell_type": "code",
|
|
"execution_count": null,
|
|
"metadata": {},
|
|
"outputs": [],
|
|
"source": [
|
|
"from qiskit import QuantumCircuit\n",
|
|
"\n",
|
|
"from quantum_learning.experiments import simulate_counts\n",
|
|
"\n",
|
|
"from quantum_learning.interactive import editable_circuit_lab, quiz_block, reflection_box, step_reference_table\n"
|
|
],
|
|
"id": "60b33a73"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"## Code-To-Diagram Reference\n",
|
|
"\n",
|
|
"The next table is the bridge between code and graphics. Each marker appears in the editable code comments. Your job is to look at a marker, identify the relevant line of code, find the corresponding structural change in the circuit diagram, and explain why that change matters for the learning objective of the notebook.\n",
|
|
"\n",
|
|
"This is the closest notebook-level substitute for clickable diagram editing that we can do robustly in a local-first workflow. It is still very useful. The markers force your attention to move back and forth between three representations of the same object: source code, circuit graphic, and conceptual explanation.\n"
|
|
],
|
|
"id": "85d018be"
|
|
},
|
|
{
|
|
"cell_type": "code",
|
|
"execution_count": null,
|
|
"metadata": {},
|
|
"outputs": [],
|
|
"source": [
|
|
"step_reference_table([{'marker': '[1]', 'code_focus': 'Prepare the source qubit', 'diagram_effect': 'Create the initial resource for the candidate design', 'why_it_matters': 'Review begins by naming what the candidate is trying to achieve.'}, {'marker': '[2]', 'code_focus': 'First extension step', 'diagram_effect': 'Spread the candidate pattern to a second qubit', 'why_it_matters': 'This reveals part of the candidate architecture.'}, {'marker': '[3]', 'code_focus': 'Second extension step', 'diagram_effect': 'Complete the three-qubit candidate pattern', 'why_it_matters': 'The full candidate can now be compared to alternatives.'}, {'marker': '[4]', 'code_focus': 'Measurement layer', 'diagram_effect': 'Expose candidate behavior for benchmarking', 'why_it_matters': 'Review requires observable evidence, not just intention.'}])\n"
|
|
],
|
|
"id": "8cf108d0"
|
|
},
|
|
{
|
|
"cell_type": "code",
|
|
"execution_count": null,
|
|
"metadata": {},
|
|
"outputs": [],
|
|
"source": [
|
|
"quiz_block([{'prompt': 'Which term best matches this definition: one proposed circuit family or implementation choice?', 'options': ['candidate design', 'review memo', 'risk', 'recommendation'], 'correct_index': 0, 'explanation': '`candidate design` is the best match because it names one proposed circuit family or implementation choice.'}, {'prompt': 'Which term best matches this definition: a structured written justification of a design decision?', 'options': ['review memo', 'risk', 'recommendation', 'candidate design'], 'correct_index': 0, 'explanation': '`review memo` is the best match because it names a structured written justification of a design decision.'}, {'prompt': 'Which term best matches this definition: a plausible failure mode or engineering concern tied to a design choice?', 'options': ['risk', 'recommendation', 'candidate design', 'review memo'], 'correct_index': 0, 'explanation': '`risk` is the best match because it names a plausible failure mode or engineering concern tied to a design choice.'}], heading='Vocabulary Drill')\n"
|
|
],
|
|
"id": "01a1adfc"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"## Editable Circuit Lab\n",
|
|
"\n",
|
|
"The next cell is the main interactive object in the notebook. The code comments contain numbered markers that match the reference table above. Edit the code, render the result, and compare what changed in the code to what changed in the circuit diagram. If the circuit contains measurements, the widget will also preview local counts so you can connect the structure to the observed outcome.\n"
|
|
],
|
|
"id": "95056a8f"
|
|
},
|
|
{
|
|
"cell_type": "code",
|
|
"execution_count": null,
|
|
"metadata": {},
|
|
"outputs": [],
|
|
"source": [
|
|
"editable_code = '\\ncircuit = QuantumCircuit(3, 3, name=\"candidate_a\")\\n# [1] prepare the logical source qubit\\ncircuit.h(0)\\n# [2] spread correlation to qubit 1\\ncircuit.cx(0, 1)\\n# [3] extend the pattern to qubit 2\\ncircuit.cx(1, 2)\\n# [4] measure for candidate comparison\\ncircuit.measure([0, 1, 2], [0, 1, 2])\\n'\n",
|
|
"\n",
|
|
"editable_circuit_lab(\n",
|
|
" initial_code=editable_code,\n",
|
|
" context={\"QuantumCircuit\": QuantumCircuit, \"simulate_counts\": simulate_counts},\n",
|
|
" title='Capstone Circuit Design Review',\n",
|
|
" instructions=\"Edit the commented code markers, re-render the circuit, and compare the changed code to the changed diagram.\",\n",
|
|
")\n"
|
|
],
|
|
"id": "f0cc4326"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"## Guided Analysis\n",
|
|
"\n",
|
|
"This cell is intentionally open-ended. It is the template for your own review memo. The notebook stops being a lecture here and becomes a studio for defended decision-making.\n",
|
|
"\n",
|
|
"Do not treat the next code cell as an optional extra. It is the interpretive half of the notebook. The editable circuit lab above helps you manipulate structure. The analysis cell below helps you connect that structure to behavior, summaries, counts, or transformations that can actually be inspected. The two parts belong together. If you only edit the circuit without interpreting the result, you are playing. If you interpret the result without editing the circuit, you are reading. The notebook is trying to make you do both.\n"
|
|
],
|
|
"id": "2f8b41ff"
|
|
},
|
|
{
|
|
"cell_type": "code",
|
|
"execution_count": null,
|
|
"metadata": {},
|
|
"outputs": [],
|
|
"source": [
|
|
"project_choice = \"\"\n",
|
|
"candidate_a = \"\"\n",
|
|
"candidate_b = \"\"\n",
|
|
"decision_metric_table = []\n",
|
|
"\n",
|
|
"{\n",
|
|
" \"project_choice\": project_choice,\n",
|
|
" \"candidate_a\": candidate_a,\n",
|
|
" \"candidate_b\": candidate_b,\n",
|
|
" \"decision_metric_table\": decision_metric_table,\n",
|
|
"}\n"
|
|
],
|
|
"id": "95c746a5"
|
|
},
|
|
{
|
|
"cell_type": "code",
|
|
"execution_count": null,
|
|
"metadata": {},
|
|
"outputs": [],
|
|
"source": [
|
|
"quiz_block([{'prompt': 'Which numbered marker should you inspect first if you want to study this diagram effect: Create the initial resource for the candidate design?', 'options': ['[1]', '[2]', '[3]', '[4]'], 'correct_index': 0, 'explanation': '[1] is correct because it is the step where Review begins by naming what the candidate is trying to achieve.'}, {'prompt': 'Which numbered marker should you inspect first if you want to study this diagram effect: Spread the candidate pattern to a second qubit?', 'options': ['[1]', '[2]', '[3]', '[4]'], 'correct_index': 1, 'explanation': '[2] is correct because it is the step where This reveals part of the candidate architecture.'}, {'prompt': 'Which numbered marker should you inspect first if you want to study this diagram effect: Complete the three-qubit candidate pattern?', 'options': ['[1]', '[2]', '[3]', '[4]'], 'correct_index': 2, 'explanation': '[3] is correct because it is the step where The full candidate can now be compared to alternatives.'}], heading='Marker Drill')\n"
|
|
],
|
|
"id": "f077f36d"
|
|
},
|
|
{
|
|
"cell_type": "code",
|
|
"execution_count": null,
|
|
"metadata": {},
|
|
"outputs": [],
|
|
"source": [
|
|
"quiz_block([{'prompt': 'What is the central shift in the capstone notebook?', 'options': ['From isolated circuits to defended design decisions', 'From quantum to classical-only programming', 'From notebooks to no writing at all'], 'correct_index': 0, 'explanation': 'The capstone is about professional review and recommendation.'}, {'prompt': 'Why compare multiple candidates?', 'options': ['Because the first idea is rarely above review', 'Because metrics are illegal otherwise', 'Because all circuits are equivalent'], 'correct_index': 0, 'explanation': 'Comparison is core to real design judgment.'}, {'prompt': 'What should a final recommendation include?', 'options': ['Only confidence and no caveats', 'Tradeoffs, evidence, and residual risks', 'A list of gate names'], 'correct_index': 1, 'explanation': 'Professional decisions remain accountable to evidence and risk.'}], heading='Checkpoint A')\n"
|
|
],
|
|
"id": "ffc3d366"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"## Extended Lecture Notes III\n",
|
|
"\n",
|
|
"Once you have run the editable lab, the next skill is interpretation. Interpretation means that you do not merely observe an output; you explain why that output is structurally consistent with the design. Many beginners stop one step too early. They see that a circuit \u201cworks\u201d and take that as proof of understanding. It is not. Understanding starts when you can say why the output pattern is plausible, which aspect of the design produced it, and which alternative designs might produce a similar signature for different reasons.\n",
|
|
"\n",
|
|
"This is also where common mistakes matter most. The usual traps in this notebook are:\n",
|
|
"\n",
|
|
"- presenting one candidate as if alternatives never existed\n",
|
|
"- using metrics without saying why those metrics matter for the task\n",
|
|
"- hiding risks because they make the final recommendation look less clean\n",
|
|
"\n",
|
|
"Read those carefully and check whether one of them is currently happening in your own head. That is a serious exercise, not a rhetorical flourish. Good teaching is partly the art of naming the wrong mental picture before it hardens into habit. Once a mistaken picture hardens, every later notebook becomes harder to learn because you are trying to place new knowledge on top of a warped frame.\n",
|
|
"\n",
|
|
"To counter those mistakes, keep the following design heuristics close at hand:\n",
|
|
"\n",
|
|
"- Always compare at least two plausible designs before making a recommendation.\n",
|
|
"- State which metrics you care about and why they matter for this problem.\n",
|
|
"- A professional recommendation includes residual risk, not just confidence.\n",
|
|
"\n",
|
|
"A heuristic is not a theorem. It is a professional shortcut for seeing what deserves attention first. Heuristics become especially valuable once notebooks stop being tiny. In large circuits, you cannot afford to rediscover every conceptual anchor from scratch. You need habits of attention. This notebook is deliberately training those habits early.\n",
|
|
"\n",
|
|
"If you want to push beyond passive understanding, use the stretch prompts as mini design studios:\n",
|
|
"\n",
|
|
"- Choose a problem from an earlier notebook and rewrite it as a full review memo with competing candidates.\n",
|
|
"- Add a hardware-aware criterion to your decision table and see whether the recommendation changes.\n",
|
|
"- Write the final recommendation in the tone of a real engineering review document.\n",
|
|
"\n",
|
|
"Treat each stretch prompt as a design review task. Make a prediction, change the circuit, compare the result to your prediction, and then explain the difference in plain language. If you do that consistently, the notebook stops being static literature and becomes a training environment. That is the actual goal.\n"
|
|
],
|
|
"id": "f522132e"
|
|
},
|
|
{
|
|
"cell_type": "code",
|
|
"execution_count": null,
|
|
"metadata": {},
|
|
"outputs": [],
|
|
"source": [
|
|
"reflection_box('Write the current circuit story in your own words. Which part still feels vague or unstable?')\n"
|
|
],
|
|
"id": "a20b1315"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"## Extended Lecture Notes V\n",
|
|
"\n",
|
|
"When people say they want to become \u201cadvanced,\u201d they often imagine harder circuits. Harder circuits do matter, but what really changes with expertise is the quality of attention. An amateur looks for what to type next. A designer looks for structural burden, hidden assumption, reusable pattern, and likely failure mode. This notebook is therefore already training advanced attention inside a beginner or intermediate topic. That is why the explanations may feel more detailed than a typical tutorial. The detail is not filler; it is attention training.\n",
|
|
"\n",
|
|
"Read this notebook as an invitation to slow your eye down. Which code comment is naming an intention? Which line is merely a local implementation detail? Which part of the diagram would you point to if asked to explain the central mechanism? Which result would convince you that your understanding is wrong? Those are design-review questions, and they can be practiced long before you become an expert. In fact, they *must* be practiced long before, because later advanced work depends on them.\n",
|
|
"\n",
|
|
"The notebook objective remains the same throughout: treat circuit design as a professional review process involving alternatives, metrics, risks, and a defended final recommendation. If you leave with only a hazy sense that the examples were interesting, the notebook has failed. If you leave able to explain the mechanism, edit the circuit, answer the quizzes, and diagnose your own confusion in precise terms, then the notebook has done its job. That is the standard you should hold yourself to. The course is meant to feel demanding in exactly that way.\n",
|
|
"\n",
|
|
"Use the remaining cells to verify that demand. Write reflections honestly. If a quiz exposes a weak point, that is useful information. If an edit breaks the circuit in a way you did not expect, that is useful information. The platform is becoming more interactive precisely so those moments happen early and often, where they can still be turned into learning rather than embarrassment.\n"
|
|
],
|
|
"id": "d69664bc"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"## Extended Lecture Notes VI\n",
|
|
"\n",
|
|
"Another reason the notebook is this text-heavy is that genuine understanding is almost always narrower than learners think. You may feel that you \u201cbasically get it\u201d after the first successful run. But what does that phrase actually mean? Can you explain the mechanism without reading? Can you alter the circuit and retain control of the narrative? Can you answer a multiple choice question designed to expose a subtle confusion? Can you review someone else\u2019s variation and say what is structurally different? If the answer to those questions is still no, then the feeling of understanding is real but premature. These notebooks are trying to move you from premature understanding to stable understanding.\n",
|
|
"\n",
|
|
"Stable understanding has a practical signature: it survives translation. If the idea still makes sense when you move from markdown to code, from code to diagram, from diagram to histogram, from histogram back to explanation, then the idea is becoming robust. That is why this notebook keeps revisiting the same material through several interfaces. The repetition is not because the course assumes you are slow. The repetition is because circuit design itself is multi-representational. Real work requires you to hold several representations of the same structure at once, and good pedagogy should reflect that fact.\n",
|
|
"\n",
|
|
"This is also why your notes matter. If you are studying seriously, the reflection prompts should not remain empty. Write what you thought before the experiment, what the circuit actually did, and what sentence now explains the difference best. Written explanation is a debugging tool for thought. It reveals vagueness that silent recognition can hide. If a sentence feels hard to write, that difficulty is diagnostic. Follow it.\n",
|
|
"\n",
|
|
"Keep returning to the notebook objective: treat circuit design as a professional review process involving alternatives, metrics, risks, and a defended final recommendation. The objective is the filter through which every output should be interpreted. The platform is not trying to flood you with local facts. It is trying to build durable design habits. Those habits come from focused repetition around a sharply defined objective, not from wandering exposure.\n"
|
|
],
|
|
"id": "becaacbf"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"## Variation Lab\n",
|
|
"\n",
|
|
"The first editable lab asked you to understand the canonical circuit faithfully. This second lab asks you to practice deliberate alteration. The challenge prompt is: **Choose a problem from an earlier notebook and rewrite it as a full review memo with competing candidates.**.\n",
|
|
"\n",
|
|
"Use the same marker comments and the same code-to-diagram discipline, but now work like a junior designer in a supervised design review. Make one intentional change at a time. Before each render, write down what you expect to happen to the circuit graphic, the text diagram, and any measured behavior. After the render, compare your prediction to the result and decide whether the notebook\u2019s learning objective is still being served or has been broken.\n",
|
|
"\n",
|
|
"This second lab matters because professional circuit design is not built by memorizing one correct object. It is built by making controlled variations and retaining explanatory control while the object changes.\n"
|
|
],
|
|
"id": "f1f7bb42"
|
|
},
|
|
{
|
|
"cell_type": "code",
|
|
"execution_count": null,
|
|
"metadata": {},
|
|
"outputs": [],
|
|
"source": [
|
|
"variation_code = '\\ncircuit = QuantumCircuit(3, 3, name=\"candidate_a\")\\n# [1] prepare the logical source qubit\\ncircuit.h(0)\\n# [2] spread correlation to qubit 1\\ncircuit.cx(0, 1)\\n# [3] extend the pattern to qubit 2\\ncircuit.cx(1, 2)\\n# [4] measure for candidate comparison\\ncircuit.measure([0, 1, 2], [0, 1, 2])\\n'\n",
|
|
"\n",
|
|
"editable_circuit_lab(\n",
|
|
" initial_code=variation_code,\n",
|
|
" context={\"QuantumCircuit\": QuantumCircuit, \"simulate_counts\": simulate_counts},\n",
|
|
" title='Capstone Circuit Design Review Variation Lab',\n",
|
|
" instructions='Implement this deliberate variation challenge: Choose a problem from an earlier notebook and rewrite it as a full review memo with competing candidates. Keep the marker comments visible, re-render after each change, and explain how the code change appears in the diagram and in any observed behavior.',\n",
|
|
")\n"
|
|
],
|
|
"id": "283bf415"
|
|
},
|
|
{
|
|
"cell_type": "code",
|
|
"execution_count": null,
|
|
"metadata": {},
|
|
"outputs": [],
|
|
"source": [
|
|
"reflection_box('After the variation lab, explain which code change most clearly altered the diagram and whether the behavioral result matched your prediction.')\n"
|
|
],
|
|
"id": "abbf676c"
|
|
},
|
|
{
|
|
"cell_type": "code",
|
|
"execution_count": null,
|
|
"metadata": {},
|
|
"outputs": [],
|
|
"source": [
|
|
"quiz_block([{'prompt': 'What weakens a design review?', 'options': ['Hiding alternatives and pretending one design was inevitable', 'Explaining tradeoffs explicitly', 'Writing a recommendation'], 'correct_index': 0, 'explanation': 'Good reviews make the decision space visible.'}, {'prompt': 'Why are metrics not enough by themselves?', 'options': ['Because judgment is still needed to interpret which metrics matter most', 'Because metrics cannot be written down', 'Because metrics only apply to single-qubit circuits'], 'correct_index': 0, 'explanation': 'Metrics inform judgment; they do not replace it.'}, {'prompt': 'What identity does the capstone aim to confirm?', 'options': ['Independent circuit designer who can defend decisions', 'Passive notebook executor', 'Purely theoretical spectator'], 'correct_index': 0, 'explanation': 'The capstone is meant to validate professional design identity.'}], heading='Checkpoint B')\n"
|
|
],
|
|
"id": "c29ffab7"
|
|
},
|
|
{
|
|
"cell_type": "code",
|
|
"execution_count": null,
|
|
"metadata": {},
|
|
"outputs": [],
|
|
"source": [
|
|
"reflection_box('Describe one design change you would now try, what you predict it would do, and why.')\n"
|
|
],
|
|
"id": "bce74aad"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"## Extended Lecture Notes VII\n",
|
|
"\n",
|
|
"One of the most important professional transitions is the move from \u201cwhat happened?\u201d to \u201cwhat should have happened, and why?\u201d That difference sounds small, but it is huge. The first question is observational. The second question is explanatory and normative. Good designers live in the second question. They are not satisfied by a plot, a diagram, or a successful run. They want a reason the result deserves trust. This notebook is training that habit even if the example itself is still relatively small.\n",
|
|
"\n",
|
|
"The deeper reason this matters is that later circuit design work becomes ambiguous. You will face multiple candidate designs, backend constraints, noisy distortion, and verification tasks that do not yield a single obvious answer. In that world, habits formed in the beginner notebooks matter enormously. If your habit is to run first and rationalize later, ambiguity will hurt you. If your habit is to predict, inspect, compare, and justify, ambiguity becomes workable. That is why even this notebook expects explanation discipline: it is building the habits you will need when the stakes become higher.\n",
|
|
"\n",
|
|
"There is also an emotional reason for this level of explanation. Many learners feel lost not because the ideas are impossible, but because the course materials they encounter fail to tell them what deserves attention. A dense, guided notebook can reduce that kind of loss. It says: here is the point of the section, here is the common confusion, here is the reason the example was chosen, here is the meaning of the output, here is the question you should now be able to answer. That guidance is not indulgent. It is efficient.\n",
|
|
"\n",
|
|
"Use the remainder of the notebook accordingly. Read slowly, answer honestly, edit boldly, and write explanations in full sentences. If the notebook feels demanding, that is correct. Professional design capability is demanding. The platform should respect that instead of pretending otherwise.\n"
|
|
],
|
|
"id": "39da6ec5"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"## Extended Lecture Notes IX\n",
|
|
"\n",
|
|
"A major source of beginner confusion is the unstable relationship between representations. You may understand the prose but not the code. Or the code but not the diagram. Or the diagram but not the output statistics. Professional circuit design requires those representations to reinforce rather than compete with one another. That is why this notebook is intentionally over-instrumented. It does not trust any single view by itself. The prose names the intention, the code implements it, the diagram spatializes it, and the output gives you something behavioral to inspect. Strong understanding emerges from agreement across those views.\n",
|
|
"\n",
|
|
"The code-to-diagram reference markers are therefore not cosmetic labels. They are anchors for translation. Translation is one of the hidden core skills in engineering. When someone says \u201cthis circuit prepares the right correlation pattern but pays too much routing overhead,\u201d they are translating among design intention, circuit structure, and hardware consequence in one sentence. If you train that translation now, later advanced notebooks will feel like larger versions of a familiar game rather than entirely new worlds.\n",
|
|
"\n",
|
|
"It also matters that the editable lab shows both a graphic and a text rendering. The graphic is better for seeing large-scale structure, symmetry, and ordering across wires. The text rendering is better for checking exact sequencing and spotting how the code expanded into a circuit object. Different renderings reveal different truths. A mature workflow uses both. If you only trust the pretty picture, you can miss a subtle sequencing detail. If you only trust the textual representation, you can miss a larger structural pattern. A serious notebook should train you to move between them without friction.\n",
|
|
"\n",
|
|
"Try to notice, too, how explanation quality changes when you point to a representation while speaking. \u201cThis line applies a Hadamard\u201d is technically true but often pedagogically weak. \u201cThis marker creates the branch point that spreads amplitude across alternatives, which is why the later controlled step can create correlation instead of acting on a single classical-looking path\u201d is much better. The second explanation links code, picture, and mechanism. It is longer because it is better. Engineering language becomes powerful when it compresses the right distinctions, not when it is short for its own sake.\n",
|
|
"\n",
|
|
"That is the deeper reason the notebooks are now much more literary. Text is not being added to compensate for weak code. Text is being used to train precise noticing. The more precisely you can narrate a circuit, the more precisely you can later design, debug, or review one.\n"
|
|
],
|
|
"id": "da9f8fed"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"## Extended Lecture Notes X\n",
|
|
"\n",
|
|
"Professional growth also requires a change in how you treat mistakes. In amateur mode, a mistake feels like proof that you do not understand the topic. In design mode, a mistake is evidence about which internal model is currently running your decisions. That is a much more useful interpretation. If you alter the circuit and the output surprises you, that surprise is not noise in the learning process. It is the learning process. It reveals the exact place where your prediction engine diverged from the actual mechanism.\n",
|
|
"\n",
|
|
"This notebook is therefore designed to create small, recoverable failures. The quizzes create retrieval failures. The editable labs create prediction failures. The reflection prompts create language failures where you discover you cannot yet say the idea as cleanly as you thought. Those failures are not a side effect. They are the point. A notebook that only ever makes you feel comfortable may be pleasant, but it will usually not be enough to create mastery.\n",
|
|
"\n",
|
|
"There is another reason to normalize this now. Later circuit design work becomes multi-objective. You will weigh depth, width, connectivity, synthesis cost, error sensitivity, measurement strategy, and verification burden at the same time. In that setting, mistakes become even more inevitable. What distinguishes a professional is not magical avoidance of error. It is fast, structured recovery. Structured recovery starts with habits like: restate the objective, inspect the main mechanism, compare expected and observed behavior, isolate the smallest meaningful change, and articulate the new hypothesis before touching the circuit again. Even beginner notebooks can practice that discipline.\n",
|
|
"\n",
|
|
"Use the variation lab in that spirit. Do not change things randomly and hope for insight. Pick a deliberate change tied to the stretch prompt, state your prediction in full sentences, then render and inspect. If the result disagrees with your prediction, write down exactly which sentence of your earlier story needs revision. That act of revision is a design skill. It is the same skill later used when transpilation distorts an elegant ideal circuit, or when a noise model exposes that a clean whiteboard intuition was incomplete.\n",
|
|
"\n",
|
|
"In short, the notebook is not merely showing you a canonical circuit. It is teaching you how to respond when a circuit stops being canonical and starts becoming yours.\n"
|
|
],
|
|
"id": "f5262f54"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"## Extended Lecture Notes XI\n",
|
|
"\n",
|
|
"A final point worth emphasizing is transfer. A notebook succeeds professionally only if the understanding it builds can be reused elsewhere. Transfer is harder than recognition. Recognition says, \u201cI remember seeing this.\u201d Transfer says, \u201cI can detect the same structural idea inside a new problem even when the surface presentation has changed.\u201d The notebook therefore keeps pointing beyond itself. It wants you to see how today\u2019s local lesson becomes tomorrow\u2019s building block in synthesis, transpilation, verification, or capstone review.\n",
|
|
"\n",
|
|
"This matters because real circuit design rarely announces its conceptual ingredients politely. A larger design may conceal a familiar principle inside many layers of implementation detail. If your earlier learning was shallow, the detail overwhelms you. If your earlier learning was principled, you start spotting the old mechanism inside the new setting. That spotting is one of the deepest rewards of good pedagogy. Suddenly complexity becomes decomposable.\n",
|
|
"\n",
|
|
"Transfer also depends on your ability to abstract without becoming vague. You do not want to say only \u201cthis is kind of like entanglement again\u201d or \u201cthis looks like another measurement issue.\u201d You want to name the operative pattern with enough precision that it can guide a design decision. That precision is exactly why the notebook keeps circling around vocabulary, design lens, and mastery gate language. The words are not there to sound formal. They are there so that, later, you can think with enough granularity to act well.\n",
|
|
"\n",
|
|
"As you finish the notebook, ask yourself a transfer question directly: if you met a new circuit tomorrow that contained the same core lesson but different gate order, different naming, or a different visualization style, what clues would tell you that the same design idea is present? If you can answer that, your learning is starting to generalize. If you cannot answer it yet, the notebook has shown you what still needs reinforcement.\n",
|
|
"\n",
|
|
"That is a demanding standard, but it is the correct one for a course aimed at professional circuit design. The goal is not merely that you remember this notebook. The goal is that you carry its reasoning power into circuits the notebook never showed you.\n"
|
|
],
|
|
"id": "0bbc37a0"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"## Extended Lecture Notes XII\n",
|
|
"\n",
|
|
"Before you leave the notebook, convert the lesson into a personal review rubric. A good rubric is specific enough to be checkable and small enough to be reused. For this notebook, a starting rubric could be: can I state the learning objective clearly, can I identify the circuit\u2019s main mechanism, can I connect each numbered marker to a visible diagram change, can I answer the quizzes without guessing, can I alter the design deliberately, and can I explain what still feels unstable? If the answer is no to any one of those, that does not mean failure. It means you have located the next repair.\n",
|
|
"\n",
|
|
"Notice how different this is from a completion mindset. Completion asks whether the notebook has been opened, run, or skimmed. A rubric asks whether the capability is present. That distinction becomes more important as the course gets harder. Advanced notebooks are full of opportunities to confuse exposure with mastery. A rubric interrupts that confusion.\n",
|
|
"\n",
|
|
"The long-term professional benefit is substantial. Designers who use rubrics learn faster because they do not rely on mood to judge progress. They rely on observable signs. Could I explain the design to another engineer? Could I predict the effect of a modification? Could I defend why one version is preferable under a stated objective? Those are observable questions. They make your study more honest and therefore more efficient.\n",
|
|
"\n",
|
|
"Keep that standard in mind as you move forward. The notebook is intentionally giving you more text, more interaction, and more chances to test yourself because the final ambition of the platform is serious. If you engage the material fully, these notebooks will stop feeling like isolated lessons and start functioning like deliberate rehearsals for real circuit design work.\n"
|
|
],
|
|
"id": "08a8bf2c"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"## Mastery Gate\n",
|
|
"\n",
|
|
"Frame a circuit problem, create at least two plausible candidates, benchmark them under explicit criteria, and write a final recommendation that names both strengths and remaining risks.\n",
|
|
"\n",
|
|
"If you cannot yet do that, do not panic. But do not pretend you have finished the notebook either. A mastery gate is not punishment. It is calibration. The whole course works only if you tell the truth about which abilities are now stable and which are still fragile.\n"
|
|
],
|
|
"id": "467e25f7"
|
|
}
|
|
],
|
|
"metadata": {
|
|
"kernelspec": {
|
|
"display_name": "QuantumLearning (.venv)",
|
|
"language": "python",
|
|
"name": "quantum-learning"
|
|
},
|
|
"language_info": {
|
|
"name": "python",
|
|
"version": "3.12"
|
|
}
|
|
},
|
|
"nbformat": 4,
|
|
"nbformat_minor": 5
|
|
}
|