mirror of
https://github.com/saymrwulf/QuantumLearning.git
synced 2026-07-28 20:11:29 +00:00
393 lines
20 KiB
Text
393 lines
20 KiB
Text
{
|
|
"cells": [
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"# Hardware-Aware Redesign Studio Lecture\n"
|
|
],
|
|
"id": "3313d111"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"<!-- COURSE_NAV_TOP -->\n",
|
|
"## Mainline Navigation\n",
|
|
"\n",
|
|
"Step 47 of 59. Follow the mainline in order and do not skip ahead.\n",
|
|
"\n",
|
|
"Previous notebook: [Qiskit Patterns and Workflow Design Studio](../module_01_qiskit_patterns/studio.ipynb)\n",
|
|
"\n",
|
|
"Next notebook: [Hardware-Aware Redesign Studio Lab](lab.ipynb)\n",
|
|
"\n",
|
|
"Rule: finish this notebook top-to-bottom before you open the next one.\n"
|
|
],
|
|
"id": "942d9e67"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"The earlier transpilation module taught you how to read compiled consequences. This professional module raises the standard. It is no longer enough to observe that the transpiler inserted extra work. You now need to decide when that burden was self-created by the abstract circuit and when a human redesign could have reduced it. This is the module where topology and basis constraints become something you actively design against rather than something you merely endure.\n"
|
|
],
|
|
"id": "a9f6f4fd"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"## Learning Objective\n",
|
|
"\n",
|
|
"\n",
|
|
" By the end of this lecture you should be able to explain how a topology or basis-gate model changes the meaning of a good abstract circuit, inspect a compiled rewrite and identify where the burden came from, and defend a manual redesign that keeps the objective stable while fitting the declared local constraints more intelligently.\n"
|
|
],
|
|
"id": "f460081a"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"A hardware-aware notebook begins with intellectual honesty about the abstract circuit. There is nothing wrong with writing the clean ideal version first. In fact, doing so is useful because it makes the original intention explicit. The mistake is pretending that the ideal structure is still automatically a good design once line topology, basis restrictions, or routing pressure enter the picture. This module is about learning when the gap between abstract intention and constrained implementation becomes large enough that a human should intervene.\n"
|
|
],
|
|
"id": "16ea691c"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"Transpilation is often introduced as a convenience layer, but in serious practice it is also a diagnostic instrument. The compiled circuit is evidence. It tells you how expensive your abstract layout became under the declared constraints. But evidence is not yet judgment. A professional designer still has to ask why the compiled circuit became expensive. Did the abstract routine force a nonlocal interaction pattern? Did the choice of control qubit create unnecessary route length? Did a reusable block remain elegant in theory but become painful on the given coupling map? Those are design questions, not compiler questions.\n"
|
|
],
|
|
"id": "71bec6d1"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"The coupling map is especially important because it turns geometry into cost. A line topology makes some interactions cheap and others awkward. That does not merely change the numbers in a summary table. It changes which circuit shapes are responsible and which are careless. A star-like entangling pattern may be perfectly readable in ideal mode and yet become an invitation to routing overhead under a line. Once you understand that, redesign stops feeling like a secondary optimization pass and starts feeling like part of the original design duty.\n"
|
|
],
|
|
"id": "21c604ae"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"Manual redesign should still be disciplined, not heroic. The goal is not to outsmart the compiler at every step or to assume that human intervention is always superior. The goal is to propose a small number of plausible alternatives whose structural relationship to the topology is clearer. If one alternative reduces compile cost while preserving the objective and the evidence path, that is useful. If not, the comparison still teaches you something about when default compilation is already doing reasonable work.\n"
|
|
],
|
|
"id": "f8135e15"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"This module also strengthens review language. Saying that a circuit is more hardware-aware because it looks less busy is weak. A better sentence says that a middle-root layout aligns the entangling structure more closely with the line topology, reducing the need for route-inducing rewrites. That kind of sentence is stronger because it names the structural reason, not only the observed outcome. The notebook should increasingly sound like engineering review, not like subjective taste.\n"
|
|
],
|
|
"id": "8aac8027"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"Hardware-aware redesign is therefore the first fully mature module in the course. It expects you to juggle ideal intention, explicit local constraints, compile evidence, and candidate comparison at once. If that feels more demanding than earlier modules, that is exactly right. Professional circuit design lives in that pressure field.\n"
|
|
],
|
|
"id": "0890256b"
|
|
},
|
|
{
|
|
"cell_type": "code",
|
|
"execution_count": null,
|
|
"metadata": {},
|
|
"outputs": [],
|
|
"source": [
|
|
"from pathlib import Path\n",
|
|
"import sys\n",
|
|
"\n",
|
|
"project_root = Path.cwd().resolve()\n",
|
|
"while not (project_root / \"pyproject.toml\").exists():\n",
|
|
" if project_root.parent == project_root:\n",
|
|
" raise RuntimeError(\"Could not locate the project root from this notebook.\")\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": "47477b8c"
|
|
},
|
|
{
|
|
"cell_type": "code",
|
|
"execution_count": null,
|
|
"metadata": {},
|
|
"outputs": [],
|
|
"source": [
|
|
"from quantum_learning import (\n",
|
|
" build_demo_noise_model,\n",
|
|
" counts_to_probabilities,\n",
|
|
" draw_circuit,\n",
|
|
" editable_circuit_lab,\n",
|
|
" evidence_checklist,\n",
|
|
" feedback_iteration_panel,\n",
|
|
" line_coupling_map,\n",
|
|
" load_assessment_blueprint,\n",
|
|
" plot_counts,\n",
|
|
" plot_probabilities,\n",
|
|
" quiz_block,\n",
|
|
" reflection_box,\n",
|
|
" rubric_scorecard,\n",
|
|
" simulate_counts,\n",
|
|
" statevector_probabilities,\n",
|
|
" step_reference_table,\n",
|
|
" transpile_summary,\n",
|
|
")\n",
|
|
"from qiskit import QuantumCircuit\n",
|
|
"from qiskit.providers.basic_provider import BasicSimulator\n"
|
|
],
|
|
"id": "ba158e17"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"## Code-To-Diagram Anchor\n",
|
|
"\n",
|
|
"\n",
|
|
" The anchor circuit is intentionally topology-hostile on a line. That is not a bug in the lesson. It is what makes the redesign problem visible. Read the reference table, inspect the abstract circuit, and then compare it to a human-aware alternative under the same local constraint model.\n"
|
|
],
|
|
"id": "57ebb0cd"
|
|
},
|
|
{
|
|
"cell_type": "code",
|
|
"execution_count": null,
|
|
"metadata": {},
|
|
"outputs": [],
|
|
"source": [
|
|
"step_reference_table([{'marker': '[1]', 'code_focus': 'Write the abstract target circuit clearly before worrying about rescue by the transpiler.', 'diagram_effect': 'The first diagram states the ideal intent with no attempt to hide topology pressure.', 'why_it_matters': 'Human redesign starts by knowing what the unpressured circuit was trying to express.'}, {'marker': '[2]', 'code_focus': 'Expose basis-gate and coupling-map assumptions explicitly.', 'diagram_effect': 'The device pressure becomes a visible part of the experiment rather than a hidden environment fact.', 'why_it_matters': 'You cannot reason about hardware cost if the constraints remain implicit.'}, {'marker': '[3]', 'code_focus': 'Inspect the compiled rewrite and decide which costs were caused by your abstract layout.', 'diagram_effect': 'The compiled version shows extra structure, depth, or routing burden.', 'why_it_matters': 'Professional redesign begins where default compilation becomes expensive.'}, {'marker': '[4]', 'code_focus': 'Create and compare a human-aware alternative instead of treating the compiler as the final word.', 'diagram_effect': 'A second circuit appears whose structure anticipates the topology rather than suffering under it.', 'why_it_matters': 'Hardware awareness is redesign, not passive observation of transpiler output.'}])\n"
|
|
],
|
|
"id": "2fe1c718"
|
|
},
|
|
{
|
|
"cell_type": "code",
|
|
"execution_count": null,
|
|
"metadata": {},
|
|
"outputs": [],
|
|
"source": [
|
|
"LOCAL_BASIS = [\"rz\", \"sx\", \"x\", \"cx\"]\n",
|
|
"\n",
|
|
"def simulate_line_counts(circuit, shots=256):\n",
|
|
" return simulate_counts(\n",
|
|
" circuit,\n",
|
|
" shots=shots,\n",
|
|
" basis_gates=LOCAL_BASIS,\n",
|
|
" coupling_map=line_coupling_map(circuit.num_qubits),\n",
|
|
" optimization_level=1,\n",
|
|
" )\n",
|
|
"\n",
|
|
"editable_code = '\\nfrom qiskit import QuantumCircuit\\n\\ndef naive_star_ghz() -> QuantumCircuit:\\n circuit = QuantumCircuit(4, 4)\\n # [1] Express the ideal entangling target directly.\\n circuit.h(0)\\n circuit.cx(0, 1)\\n circuit.cx(0, 2)\\n circuit.cx(0, 3)\\n # [2] Keep the evidence path stable while topology pressure is studied elsewhere.\\n circuit.measure([0, 1, 2, 3], [0, 1, 2, 3])\\n return circuit\\n\\ncircuit = naive_star_ghz()\\n'\n",
|
|
"editable_circuit_lab(\n",
|
|
" initial_code=editable_code,\n",
|
|
" context={\"QuantumCircuit\": QuantumCircuit, \"simulate_counts\": simulate_line_counts},\n",
|
|
" title='Hardware-Aware Redesign Studio Anchor',\n",
|
|
" instructions='Edit one structural burden at a time and use the reference table to keep the code and the engineering story aligned.',\n",
|
|
" shots=256,\n",
|
|
")\n"
|
|
],
|
|
"id": "177f3e58"
|
|
},
|
|
{
|
|
"cell_type": "code",
|
|
"execution_count": null,
|
|
"metadata": {},
|
|
"outputs": [],
|
|
"source": [
|
|
"LOCAL_BASIS = [\"rz\", \"sx\", \"x\", \"cx\"]\n",
|
|
"\n",
|
|
"def naive_star_ghz() -> QuantumCircuit:\n",
|
|
" circuit = QuantumCircuit(4, 4)\n",
|
|
" circuit.h(0)\n",
|
|
" circuit.cx(0, 1)\n",
|
|
" circuit.cx(0, 2)\n",
|
|
" circuit.cx(0, 3)\n",
|
|
" circuit.measure([0, 1, 2, 3], [0, 1, 2, 3])\n",
|
|
" return circuit\n",
|
|
"\n",
|
|
"def middle_root_ghz() -> QuantumCircuit:\n",
|
|
" circuit = QuantumCircuit(4, 4)\n",
|
|
" circuit.h(1)\n",
|
|
" circuit.cx(1, 0)\n",
|
|
" circuit.cx(1, 2)\n",
|
|
" circuit.cx(2, 3)\n",
|
|
" circuit.measure([0, 1, 2, 3], [0, 1, 2, 3])\n",
|
|
" return circuit\n",
|
|
"\n",
|
|
"results = []\n",
|
|
"for name, builder in [(\"naive\", naive_star_ghz), (\"middle_root\", middle_root_ghz)]:\n",
|
|
" circuit = builder()\n",
|
|
" summary = transpile_summary(\n",
|
|
" circuit,\n",
|
|
" BasicSimulator(),\n",
|
|
" basis_gates=LOCAL_BASIS,\n",
|
|
" coupling_map=line_coupling_map(4),\n",
|
|
" optimization_level=1,\n",
|
|
" )\n",
|
|
" results.append(\n",
|
|
" {\n",
|
|
" \"candidate\": name,\n",
|
|
" \"depth_after\": summary[\"depth_after\"],\n",
|
|
" \"size_after\": summary[\"size_after\"],\n",
|
|
" \"ops_after\": summary[\"ops_after\"],\n",
|
|
" }\n",
|
|
" )\n",
|
|
"\n",
|
|
"results\n"
|
|
],
|
|
"id": "176f7485"
|
|
},
|
|
{
|
|
"cell_type": "code",
|
|
"execution_count": null,
|
|
"metadata": {},
|
|
"outputs": [],
|
|
"source": [
|
|
"quiz_block([{'prompt': 'What is the first mistake hardware-aware redesign tries to prevent?', 'options': ['Letting the transpiler quietly rescue a topology-hostile abstract circuit without inspecting the cost', 'Using any two-qubit gate at all', 'Running local simulation before cloud execution'], 'correct_index': 0, 'explanation': 'Hardware awareness begins by exposing compilation pressure, not ignoring it.'}, {'prompt': 'Why must coupling maps be explicit in a redesign notebook?', 'options': ['Because the constraints shape what counts as a good circuit', 'Because they increase the number of qubits in the circuit', 'Because Qiskit cannot run without them'], 'correct_index': 0, 'explanation': 'The whole redesign question depends on visible constraints.'}], heading='Lecture Checkpoint A')\n"
|
|
],
|
|
"id": "b4d883a1"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"A strong self-check in this module is whether you can explain compile inflation in structural terms. If all you can say is that the transpiled circuit got deeper, you have observed a symptom but not yet analyzed a cause. Professional redesign begins when you can name the abstract interaction pattern that invited the cost.\n"
|
|
],
|
|
"id": "0c62c028"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"Another self-check is whether your redesign keeps the objective stable. It is easy to make a circuit cheaper by quietly changing what it is trying to do. That is not redesign. That is drift. The discipline of this module is to keep the intended behavior and reporting contract fixed while the internal structure is reconsidered under constraints.\n"
|
|
],
|
|
"id": "1fc5694c"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"## Reading Discipline For This Module\n",
|
|
"\n",
|
|
"The professional band demands slower reading than the earlier bands because the unit of judgment is larger. You are no longer inspecting only a circuit body. You are inspecting a design brief, a constraint model, a verification story, or a recommendation workflow. That means every notebook should be read with questions like these in mind: what burden is this stage carrying, what evidence would justify it, and what kind of failure would falsify the current explanation? If those questions stay active while you read, the notebook becomes training. If they disappear, the notebook becomes performance.\n",
|
|
"\n",
|
|
"Another discipline worth installing here is conditional confidence. Professional engineering rarely says only \"this works.\" It says \"under these assumptions, with this evidence, this is the choice I recommend.\" That conditional phrasing is not weakness. It is rigor. The purpose of the final band is to make that rigor normal in both your code and your prose.\n"
|
|
],
|
|
"id": "f803ed7a"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"## Professional Review Habit\n",
|
|
"\n",
|
|
"Another habit worth building here is review-minded reading. Do not read these notebooks only as the author of the current code cell. Read them as the future reviewer who must decide whether the workflow, redesign, diagnosis, or recommendation is trustworthy. That reviewer wants to know what assumptions were fixed, what evidence was gathered, what remained uncertain, and what could still break if the surrounding constraints changed. Practicing that perspective now is what turns the final band into professional training instead of advanced entertainment.\n"
|
|
],
|
|
"id": "9a5981c0"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"## Forward Link\n",
|
|
"\n",
|
|
"Every later notebook artifact in a real project will inherit the standards practiced here. Workflow patterns affect how experiments are reproduced. Hardware-aware redesign affects whether ideal elegance survives implementation. Verification determines whether bad results are diagnosed honestly. And capstone review determines whether a chosen circuit can actually be defended. The point of this band is not to add optional polish. It is to make the entire project behave like professional engineering work.\n"
|
|
],
|
|
"id": "1c208e9a"
|
|
},
|
|
{
|
|
"cell_type": "code",
|
|
"execution_count": null,
|
|
"metadata": {},
|
|
"outputs": [],
|
|
"source": [
|
|
"quiz_block([{'prompt': 'What makes a manual redesign better than passive transpiler inspection?', 'options': ['It anticipates the topology in the abstract design instead of paying routing cost after the fact', 'It removes the need to benchmark', 'It always lowers gate counts to the theoretical minimum'], 'correct_index': 0, 'explanation': 'Human redesign aims to reduce avoidable compiler burden.'}, {'prompt': 'Why keep the reporting layer stable while redesigning the entangling body?', 'options': ['So behavioral comparisons stay fair while structure changes', 'Because classical bits cannot be moved in Qiskit', 'Because metrics only work on measured circuits'], 'correct_index': 0, 'explanation': 'A stable objective is necessary for meaningful redesign comparison.'}], heading='Lecture Checkpoint B')\n"
|
|
],
|
|
"id": "55001cca"
|
|
},
|
|
{
|
|
"cell_type": "code",
|
|
"execution_count": null,
|
|
"metadata": {},
|
|
"outputs": [],
|
|
"source": [
|
|
"reflection_box('Explain why a compiled circuit is evidence but not yet a final design verdict.')\n"
|
|
],
|
|
"id": "60d25177"
|
|
},
|
|
{
|
|
"cell_type": "code",
|
|
"execution_count": null,
|
|
"metadata": {},
|
|
"outputs": [],
|
|
"source": [
|
|
"reflection_box('Describe one structural feature that can make an abstract circuit needlessly hostile to a line topology.')\n"
|
|
],
|
|
"id": "88fda4b5"
|
|
},
|
|
{
|
|
"cell_type": "code",
|
|
"execution_count": null,
|
|
"metadata": {},
|
|
"outputs": [],
|
|
"source": [
|
|
"feedback_iteration_panel(title='Hardware-Aware Redesign Studio Lecture Revision Loop', prompt='State the judgement this lecture is training, the strongest evidence that would justify it, the current weakness in your own explanation, and the next revision you should make.')\n"
|
|
],
|
|
"id": "7a1214ce"
|
|
},
|
|
{
|
|
"cell_type": "code",
|
|
"execution_count": null,
|
|
"metadata": {},
|
|
"outputs": [],
|
|
"source": [
|
|
"assessment_blueprint = load_assessment_blueprint()\n",
|
|
"rubric_scorecard(\n",
|
|
" assessment_blueprint.get_rubric('module_self_review'),\n",
|
|
" title='Hardware-Aware Redesign Studio Lecture Self-Grading',\n",
|
|
")\n"
|
|
],
|
|
"id": "73c12df7"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"## Mastery Gate\n",
|
|
"\n",
|
|
"Leave this lecture only when you can explain what evidence would justify the final professional judgment and what evidence would force you to revise it.\n"
|
|
],
|
|
"id": "bb2db81a"
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"<!-- COURSE_NAV_BOTTOM -->\n",
|
|
"## What To Open Next\n",
|
|
"\n",
|
|
"Next notebook: [Hardware-Aware Redesign Studio Lab](lab.ipynb)\n",
|
|
"\n",
|
|
"When you finish this notebook, open the next notebook shown above. Stay on the guarded mainline route.\n"
|
|
],
|
|
"id": "b1e74c49"
|
|
}
|
|
],
|
|
"metadata": {
|
|
"kernelspec": {
|
|
"display_name": "QuantumLearning (.venv)",
|
|
"language": "python",
|
|
"name": "quantum-learning"
|
|
},
|
|
"language_info": {
|
|
"name": "python",
|
|
"version": "3.12"
|
|
}
|
|
},
|
|
"nbformat": 4,
|
|
"nbformat_minor": 5
|
|
}
|