qsharp-lang 1.0.32-dev → 1.0.34-dev
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/katas-content.generated.js +17 -17
- package/dist/log.js +2 -3
- package/dist/ux/ticks.d.ts +6 -0
- package/dist/ux/ticks.js +125 -0
- package/lib/node/qsc_wasm.cjs +85 -92
- package/lib/node/qsc_wasm.d.cts +1 -1
- package/lib/node/qsc_wasm_bg.wasm +0 -0
- package/lib/web/qsc_wasm.d.ts +1 -1
- package/lib/web/qsc_wasm.js +80 -90
- package/lib/web/qsc_wasm_bg.wasm +0 -0
- package/package.json +1 -1
- package/ux/colormap.ts +51 -0
- package/ux/data.ts +68 -0
- package/ux/estimatesOverview.tsx +238 -0
- package/ux/generate_report_code.py +243 -0
- package/ux/index.ts +4 -2
- package/ux/output_data.md +537 -0
- package/ux/qsharp-ux.css +37 -0
- package/ux/reTable.tsx +7 -28
- package/ux/report.ts +591 -0
- package/ux/resultsTable.tsx +35 -49
- package/ux/scatterChart.tsx +369 -0
- package/ux/spaceChart.tsx +2 -2
|
@@ -0,0 +1,537 @@
|
|
|
1
|
+
---
|
|
2
|
+
geometry:
|
|
3
|
+
- left=1cm
|
|
4
|
+
- right=1cm
|
|
5
|
+
- top=1cm
|
|
6
|
+
- bottom=2cm
|
|
7
|
+
classoption:
|
|
8
|
+
- 10pt
|
|
9
|
+
...
|
|
10
|
+
|
|
11
|
+
# Output data
|
|
12
|
+
|
|
13
|
+
In this document, we describe all output parameters which are printed by the Azure Quantum Resource Estimator. Second-level headings contain one group in the output that consists of a header and a table with resource estimation data. Each third-level heading corresponds to an entry, which is preceded by a short description text in italic and a long description text. The short description text will be always visible in the third column next to the value, whereas the long description text will be visible as a tooltip when hovering over the corresponding row in the table. The description texts may contain some variable names such as `variable` or $\mathtt{variable}$ in formulas. These will be substituted by the actual computed values extracted from the resource estimates.
|
|
14
|
+
|
|
15
|
+
## Physical resource estimates
|
|
16
|
+
|
|
17
|
+
### Runtime
|
|
18
|
+
|
|
19
|
+
[//]: # "physicalCountsFormatted/runtime"
|
|
20
|
+
|
|
21
|
+
_Total runtime_
|
|
22
|
+
|
|
23
|
+
This is a runtime estimate for the execution time of the algorithm. In general, the execution time corresponds to the duration of one logical cycle (`logicalQubit/logicalCycleTime` nanosecs) multiplied by the `physicalCounts/breakdown/algorithmicLogicalDepth` logical cycles to run the algorithm. If however the duration of a single T factory (here: `tfactory/runtime` nanosecs) is larger than the algorithm runtime, we extend the number of logical cycles artificially in order to exceed the runtime of a single T factory.
|
|
24
|
+
|
|
25
|
+
### rQOPS
|
|
26
|
+
|
|
27
|
+
[//]: # "physicalCountsFormatted/rqops"
|
|
28
|
+
|
|
29
|
+
_Reliable quantum operations per second_
|
|
30
|
+
|
|
31
|
+
The value is computed as the number of logical qubits after layout (`physicalCounts/breakdown/algorithmicLogicalQubits`) (with a logical error rate of `physicalCountsFormatted/requiredLogicalQubitErrorRate`) multiplied by the clock frequency (`logicalQubit/logicalCyclesPerSecond`), which is the number of logical cycles per second.
|
|
32
|
+
|
|
33
|
+
### Physical qubits
|
|
34
|
+
|
|
35
|
+
[//]: # "physicalCountsFormatted/physicalQubits"
|
|
36
|
+
|
|
37
|
+
_Number of physical qubits_
|
|
38
|
+
|
|
39
|
+
This value represents the total number of physical qubits, which is the sum of `physicalCounts/breakdown/physicalQubitsForAlgorithm` physical qubits to implement the algorithm logic, and `physicalCounts/breakdown/physicalQubitsForTfactories` physical qubits to execute the T factories that are responsible to produce the T states that are consumed by the algorithm.
|
|
40
|
+
|
|
41
|
+
## Resource estimates breakdown
|
|
42
|
+
|
|
43
|
+
### Logical algorithmic qubits
|
|
44
|
+
|
|
45
|
+
[//]: # "physicalCountsFormatted/algorithmicLogicalQubits"
|
|
46
|
+
|
|
47
|
+
_Number of logical qubits for the algorithm after layout_
|
|
48
|
+
|
|
49
|
+
Laying out the logical qubits in the presence of nearest-neighbor constraints requires additional logical qubits. In particular, to layout the $Q_{\rm alg} = \mathtt{logicalCounts/numQubits}$ logical qubits in the input algorithm, we require in total $2 \cdot Q_{\rm alg} + \lceil \sqrt{8 \cdot Q_{\rm alg}}\rceil + 1 = \mathtt{physicalCounts/breakdown/algorithmicLogicalQubits}$ logical qubits.
|
|
50
|
+
|
|
51
|
+
### Algorithmic depth
|
|
52
|
+
|
|
53
|
+
[//]: # "physicalCountsFormatted/algorithmicLogicalDepth"
|
|
54
|
+
|
|
55
|
+
_Number of logical cycles for the algorithm_
|
|
56
|
+
|
|
57
|
+
To execute the algorithm using _Parallel Synthesis Sequential Pauli Computation_ (PSSPC), operations are scheduled in terms of multi-qubit Pauli measurements, for which assume an execution time of one logical cycle. Based on the input algorithm, we require one multi-qubit measurement for the `logicalCounts/measurementCount` single-qubit measurements, the `logicalCounts/rotationCount` arbitrary single-qubit rotations, and the `logicalCounts/tCount` T gates, three multi-qubit measurements for each of the `logicalCounts/cczCount` CCZ and `logicalCounts/ccixCount` CCiX gates in the input program, as well as `physicalCountsFormatted/numTsPerRotation` multi-qubit measurements for each of the `logicalCounts/rotationDepth` non-Clifford layers in which there is at least one single-qubit rotation with an arbitrary angle rotation.
|
|
58
|
+
|
|
59
|
+
### Logical depth
|
|
60
|
+
|
|
61
|
+
[//]: # "physicalCountsFormatted/logicalDepth"
|
|
62
|
+
|
|
63
|
+
_Number of logical cycles performed_
|
|
64
|
+
|
|
65
|
+
This number is usually equal to the logical depth of the algorithm, which is `physicalCounts/breakdown/algorithmicLogicalDepth`. However, in the case in which a single T factory is slower than the execution time of the algorithm, we adjust the logical cycle depth to exceed the T factory's execution time.
|
|
66
|
+
|
|
67
|
+
### Clock frequency
|
|
68
|
+
|
|
69
|
+
[//]: # "physicalCountsFormatted/clockFrequency"
|
|
70
|
+
|
|
71
|
+
_Number of logical cycles per second_
|
|
72
|
+
|
|
73
|
+
This is the number of logical cycles that can be performed within one second. The logical cycle time is `physicalCountsFormatted/logicalCycleTime`.
|
|
74
|
+
|
|
75
|
+
### Number of T states
|
|
76
|
+
|
|
77
|
+
[//]: # "physicalCountsFormatted/numTstates"
|
|
78
|
+
|
|
79
|
+
_Number of T states consumed by the algorithm_
|
|
80
|
+
|
|
81
|
+
To execute the algorithm, we require one T state for each of the `logicalCounts/tCount` T gates, four T states for each of the `logicalCounts/cczCount` CCZ and `logicalCounts/ccixCount` CCiX gates, as well as `physicalCountsFormatted/numTsPerRotation` for each of the `logicalCounts/rotationCount` single-qubit rotation gates with arbitrary angle rotation.
|
|
82
|
+
|
|
83
|
+
### Number of T factories
|
|
84
|
+
|
|
85
|
+
[//]: # "physicalCountsFormatted/numTfactories"
|
|
86
|
+
|
|
87
|
+
_Number of T factories capable of producing the demanded `physicalCounts/breakdown/numTstates` T states during the algorithm's runtime_
|
|
88
|
+
|
|
89
|
+
The total number of T factories `physicalCounts/breakdown/numTfactories` that are executed in parallel is computed as $\left\lceil\dfrac{\text{T states}\cdot\text{T factory duration}}{\text{T states per T factory}\cdot\text{algorithm runtime}}\right\rceil = \left\lceil\dfrac{\mathtt{physicalCounts/breakdown/numTstates} \cdot \mathtt{tfactory/runtime}\;\text{ns}}{\mathtt{tfactory/numTstates} \cdot \mathtt{physicalCounts/runtime}\;\text{ns}}\right\rceil$
|
|
90
|
+
|
|
91
|
+
### Number of T factory invocations
|
|
92
|
+
|
|
93
|
+
[//]: # "physicalCountsFormatted/numTfactoryRuns"
|
|
94
|
+
|
|
95
|
+
_Number of times all T factories are invoked_
|
|
96
|
+
|
|
97
|
+
In order to prepare the `physicalCounts/breakdown/numTstates` T states, the `physicalCounts/breakdown/numTfactories` copies of the T factory are repeatedly invoked `physicalCounts/breakdown/numTfactoryRuns` times.
|
|
98
|
+
|
|
99
|
+
### Physical algorithmic qubits
|
|
100
|
+
|
|
101
|
+
[//]: # "physicalCountsFormatted/physicalQubitsForAlgorithm"
|
|
102
|
+
|
|
103
|
+
_Number of physical qubits for the algorithm after layout_
|
|
104
|
+
|
|
105
|
+
The `physicalCounts/breakdown/physicalQubitsForAlgorithm` are the product of the `physicalCounts/breakdown/algorithmicLogicalQubits` logical qubits after layout and the `logicalQubit/physicalQubits` physical qubits that encode a single logical qubit.
|
|
106
|
+
|
|
107
|
+
### Physical T factory qubits
|
|
108
|
+
|
|
109
|
+
[//]: # "physicalCountsFormatted/physicalQubitsForTfactories"
|
|
110
|
+
|
|
111
|
+
_Number of physical qubits for the T factories_
|
|
112
|
+
|
|
113
|
+
Each T factory requires `tfactory/physicalQubits` physical qubits and we run `physicalCounts/breakdown/numTfactories` in parallel, therefore we need $\mathtt{physicalCounts/breakdown/physicalQubitsForTfactories} = \mathtt{tfactory/physicalQubits} \cdot \mathtt{physicalCounts/breakdown/numTfactories}$ qubits.
|
|
114
|
+
|
|
115
|
+
### Required logical qubit error rate
|
|
116
|
+
|
|
117
|
+
[//]: # "physicalCountsFormatted/requiredLogicalQubitErrorRate"
|
|
118
|
+
|
|
119
|
+
_The minimum logical qubit error rate required to run the algorithm within the error budget_
|
|
120
|
+
|
|
121
|
+
The minimum logical qubit error rate is obtained by dividing the logical error probability `physicalCountsFormatted/errorBudgetLogical` by the product of `physicalCounts/breakdown/algorithmicLogicalQubits` logical qubits and the total cycle count `physicalCounts/breakdown/logicalDepth`.
|
|
122
|
+
|
|
123
|
+
### Required logical T state error rate
|
|
124
|
+
|
|
125
|
+
[//]: # "physicalCountsFormatted/requiredLogicalTstateErrorRate"
|
|
126
|
+
|
|
127
|
+
_The minimum T state error rate required for distilled T states_
|
|
128
|
+
|
|
129
|
+
The minimum T state error rate is obtained by dividing the T distillation error probability `physicalCountsFormatted/errorBudgetTstates` by the total number of T states `physicalCounts/breakdown/numTstates`.
|
|
130
|
+
|
|
131
|
+
### Number of T states per rotation
|
|
132
|
+
|
|
133
|
+
[//]: # "physicalCountsFormatted/numTsPerRotation"
|
|
134
|
+
|
|
135
|
+
_Number of T states to implement a rotation with an arbitrary angle_
|
|
136
|
+
|
|
137
|
+
The number of T states to implement a rotation with an arbitrary angle is $\lceil 0.53 \log_2(\mathtt{logicalCounts/rotationCount} / \mathtt{errorBudget/rotations}) + 5.3\rceil$ [[arXiv:2203.10064](https://arxiv.org/abs/2203.10064)]. For simplicity, we use this formula for all single-qubit arbitrary angle rotations, and do not distinguish between best, worst, and average cases.
|
|
138
|
+
|
|
139
|
+
## Logical qubit parameters
|
|
140
|
+
|
|
141
|
+
### QEC scheme
|
|
142
|
+
|
|
143
|
+
[//]: # "jobParams/qecScheme/name"
|
|
144
|
+
|
|
145
|
+
_Name of QEC scheme_
|
|
146
|
+
|
|
147
|
+
You can load pre-defined QEC schemes by using the name `surface_code` or `floquet_code`. The latter only works with Majorana qubits.
|
|
148
|
+
|
|
149
|
+
### Code distance
|
|
150
|
+
|
|
151
|
+
[//]: # "logicalQubit/codeDistance"
|
|
152
|
+
|
|
153
|
+
_Required code distance for error correction_
|
|
154
|
+
|
|
155
|
+
The code distance is the smallest odd integer greater or equal to $\dfrac{2\log(\mathtt{jobParams/qecScheme/crossingPrefactor} / \mathtt{physicalCounts/breakdown/requiredLogicalQubitErrorRate})}{\log(\mathtt{jobParams/qecScheme/errorCorrectionThreshold}/\mathtt{physicalCounts/breakdown/cliffordErrorRate})} - 1$
|
|
156
|
+
|
|
157
|
+
### Physical qubits
|
|
158
|
+
|
|
159
|
+
[//]: # "physicalCountsFormatted/physicalQubitsPerLogicalQubit"
|
|
160
|
+
|
|
161
|
+
_Number of physical qubits per logical qubit_
|
|
162
|
+
|
|
163
|
+
The number of physical qubits per logical qubit are evaluated using the formula `jobParams/qecScheme/physicalQubitsPerLogicalQubit` that can be user-specified.
|
|
164
|
+
|
|
165
|
+
### Logical cycle time
|
|
166
|
+
|
|
167
|
+
[//]: # "physicalCountsFormatted/logicalCycleTime"
|
|
168
|
+
|
|
169
|
+
_Duration of a logical cycle in nanoseconds_
|
|
170
|
+
|
|
171
|
+
The runtime of one logical cycle in nanoseconds is evaluated using the formula `jobParams/qecScheme/logicalCycleTime` that can be user-specified.
|
|
172
|
+
|
|
173
|
+
### Logical qubit error rate
|
|
174
|
+
|
|
175
|
+
[//]: # "physicalCountsFormatted/logicalErrorRate"
|
|
176
|
+
|
|
177
|
+
_Logical qubit error rate_
|
|
178
|
+
|
|
179
|
+
The logical qubit error rate is computed as $\mathtt{jobParams/qecScheme/crossingPrefactor} \cdot \left(\dfrac{\mathtt{physicalCounts/breakdown/cliffordErrorRate}}{\mathtt{jobParams/qecScheme/errorCorrectionThreshold}}\right)^\frac{\mathtt{logicalQubit/codeDistance} + 1}{2}$
|
|
180
|
+
|
|
181
|
+
### Crossing prefactor
|
|
182
|
+
|
|
183
|
+
[//]: # "jobParams/qecScheme/crossingPrefactor"
|
|
184
|
+
|
|
185
|
+
_Crossing prefactor used in QEC scheme_
|
|
186
|
+
|
|
187
|
+
The crossing prefactor is usually extracted numerically from simulations when fitting an exponential curve to model the relationship between logical and physical error rate.
|
|
188
|
+
|
|
189
|
+
### Error correction threshold
|
|
190
|
+
|
|
191
|
+
[//]: # "jobParams/qecScheme/errorCorrectionThreshold"
|
|
192
|
+
|
|
193
|
+
_Error correction threshold used in QEC scheme_
|
|
194
|
+
|
|
195
|
+
The error correction threshold is the physical error rate below which the error rate of the logical qubit is less than the error rate of the physical qubit that constitute it. This value is usually extracted numerically from simulations of the logical error rate.
|
|
196
|
+
|
|
197
|
+
### Logical cycle time formula
|
|
198
|
+
|
|
199
|
+
[//]: # "jobParams/qecScheme/logicalCycleTime"
|
|
200
|
+
|
|
201
|
+
_QEC scheme formula used to compute logical cycle time_
|
|
202
|
+
|
|
203
|
+
This is the formula that is used to compute the logical cycle time `logicalQubit/logicalCycleTime` ns.
|
|
204
|
+
|
|
205
|
+
### Physical qubits formula
|
|
206
|
+
|
|
207
|
+
[//]: # "jobParams/qecScheme/physicalQubitsPerLogicalQubit"
|
|
208
|
+
|
|
209
|
+
_QEC scheme formula used to compute number of physical qubits per logical qubit_
|
|
210
|
+
|
|
211
|
+
This is the formula that is used to compute the number of physical qubits per logical qubits `logicalQubit/physicalQubits`.
|
|
212
|
+
|
|
213
|
+
## T factory parameters
|
|
214
|
+
|
|
215
|
+
### Physical qubits
|
|
216
|
+
|
|
217
|
+
[//]: # "physicalCountsFormatted/tfactoryPhysicalQubits"
|
|
218
|
+
|
|
219
|
+
_Number of physical qubits for a single T factory_
|
|
220
|
+
|
|
221
|
+
This corresponds to the maximum number of physical qubits over all rounds of T distillation units in a T factory. A round of distillation contains of multiple copies of distillation units to achieve the required success probability of producing a T state with the expected logical T state error rate.
|
|
222
|
+
|
|
223
|
+
### Runtime
|
|
224
|
+
|
|
225
|
+
[//]: # "physicalCountsFormatted/tfactoryRuntime"
|
|
226
|
+
|
|
227
|
+
_Runtime of a single T factory_
|
|
228
|
+
|
|
229
|
+
The runtime of a single T factory is the accumulated runtime of executing each round in a T factory.
|
|
230
|
+
|
|
231
|
+
### Number of output T states per run
|
|
232
|
+
|
|
233
|
+
[//]: # "tfactory/numTstates"
|
|
234
|
+
|
|
235
|
+
_Number of output T states produced in a single run of T factory_
|
|
236
|
+
|
|
237
|
+
The T factory takes as input `tfactory/numInputTstates` noisy physical T states with an error rate of `jobParams/qubitParams/tGateErrorRate` and produces `tfactory/numTstates` T states with an error rate of `physicalCountsFormatted/tstateLogicalErrorRate`.
|
|
238
|
+
|
|
239
|
+
### Number of input T states per run
|
|
240
|
+
|
|
241
|
+
[//]: # "physicalCountsFormatted/numInputTstates"
|
|
242
|
+
|
|
243
|
+
_Number of physical input T states consumed in a single run of a T factory_
|
|
244
|
+
|
|
245
|
+
This value includes the physical input T states of all copies of the distillation unit in the first round.
|
|
246
|
+
|
|
247
|
+
### Distillation rounds
|
|
248
|
+
|
|
249
|
+
[//]: # "tfactory/numRounds"
|
|
250
|
+
|
|
251
|
+
_The number of distillation rounds_
|
|
252
|
+
|
|
253
|
+
This is the number of distillation rounds. In each round one or multiple copies of some distillation unit is executed.
|
|
254
|
+
|
|
255
|
+
### Distillation units per round
|
|
256
|
+
|
|
257
|
+
[//]: # "physicalCountsFormatted/numUnitsPerRound"
|
|
258
|
+
|
|
259
|
+
_The number of units in each round of distillation_
|
|
260
|
+
|
|
261
|
+
This is the number of copies for the distillation units per round.
|
|
262
|
+
|
|
263
|
+
### Distillation units
|
|
264
|
+
|
|
265
|
+
[//]: # "physicalCountsFormatted/unitNamePerRound"
|
|
266
|
+
|
|
267
|
+
_The types of distillation units_
|
|
268
|
+
|
|
269
|
+
These are the types of distillation units that are executed in each round. The units can be either physical or logical, depending on what type of qubit they are operating. Space-efficient units require fewer qubits for the cost of longer runtime compared to Reed-Muller preparation units.
|
|
270
|
+
|
|
271
|
+
### Distillation code distances
|
|
272
|
+
|
|
273
|
+
[//]: # "physicalCountsFormatted/codeDistancePerRound"
|
|
274
|
+
|
|
275
|
+
_The code distance in each round of distillation_
|
|
276
|
+
|
|
277
|
+
This is the code distance used for the units in each round. If the code distance is 1, then the distillation unit operates on physical qubits instead of error-corrected logical qubits.
|
|
278
|
+
|
|
279
|
+
### Number of physical qubits per round
|
|
280
|
+
|
|
281
|
+
[//]: # "physicalCountsFormatted/physicalQubitsPerRound"
|
|
282
|
+
|
|
283
|
+
_The number of physical qubits used in each round of distillation_
|
|
284
|
+
|
|
285
|
+
The maximum number of physical qubits over all rounds is the number of physical qubits for the T factory, since qubits are reused by different rounds.
|
|
286
|
+
|
|
287
|
+
### Runtime per round
|
|
288
|
+
|
|
289
|
+
[//]: # "physicalCountsFormatted/tfactoryRuntimePerRound"
|
|
290
|
+
|
|
291
|
+
_The runtime of each distillation round_
|
|
292
|
+
|
|
293
|
+
The runtime of the T factory is the sum of the runtimes in all rounds.
|
|
294
|
+
|
|
295
|
+
### Logical T state error rate
|
|
296
|
+
|
|
297
|
+
[//]: # "physicalCountsFormatted/tstateLogicalErrorRate"
|
|
298
|
+
|
|
299
|
+
_Logical T state error rate_
|
|
300
|
+
|
|
301
|
+
This is the logical T state error rate achieved by the T factory which is equal or smaller than the required error rate `physicalCountsFormatted/requiredLogicalTstateErrorRate`.
|
|
302
|
+
|
|
303
|
+
## Pre-layout logical resources
|
|
304
|
+
|
|
305
|
+
### Logical qubits (pre-layout)
|
|
306
|
+
|
|
307
|
+
[//]: # "physicalCountsFormatted/logicalCountsNumQubits"
|
|
308
|
+
|
|
309
|
+
_Number of logical qubits in the input quantum program_
|
|
310
|
+
|
|
311
|
+
We determine `physicalCounts/breakdown/algorithmicLogicalQubits` algorithmic logical qubits from this number by assuming to align them in a 2D grid. Auxiliary qubits are added to allow for sufficient space to execute multi-qubit Pauli measurements on all or a subset of the logical qubits.
|
|
312
|
+
|
|
313
|
+
### T gates
|
|
314
|
+
|
|
315
|
+
[//]: # "physicalCountsFormatted/logicalCountsTCount"
|
|
316
|
+
|
|
317
|
+
_Number of T gates in the input quantum program_
|
|
318
|
+
|
|
319
|
+
This includes all T gates and adjoint T gates, but not T gates used to implement rotation gates with arbitrary angle, CCZ gates, or CCiX gates.
|
|
320
|
+
|
|
321
|
+
### Rotation gates
|
|
322
|
+
|
|
323
|
+
[//]: # "physicalCountsFormatted/logicalCountsRotationCount"
|
|
324
|
+
|
|
325
|
+
_Number of rotation gates in the input quantum program_
|
|
326
|
+
|
|
327
|
+
This is the number of all rotation gates. If an angle corresponds to a Pauli, Clifford, or T gate, it is not accounted for in this number.
|
|
328
|
+
|
|
329
|
+
### Rotation depth
|
|
330
|
+
|
|
331
|
+
[//]: # "physicalCountsFormatted/logicalCountsRotationDepth"
|
|
332
|
+
|
|
333
|
+
_Depth of rotation gates in the input quantum program_
|
|
334
|
+
|
|
335
|
+
This is the number of all non-Clifford layers that include at least one single-qubit rotation gate with an arbitrary angle.
|
|
336
|
+
|
|
337
|
+
### CCZ gates
|
|
338
|
+
|
|
339
|
+
[//]: # "physicalCountsFormatted/logicalCountsCczCount"
|
|
340
|
+
|
|
341
|
+
_Number of CCZ-gates in the input quantum program_
|
|
342
|
+
|
|
343
|
+
This is the number of CCZ gates.
|
|
344
|
+
|
|
345
|
+
### CCiX gates
|
|
346
|
+
|
|
347
|
+
[//]: # "physicalCountsFormatted/logicalCountsCcixCount"
|
|
348
|
+
|
|
349
|
+
_Number of CCiX-gates in the input quantum program_
|
|
350
|
+
|
|
351
|
+
This is the number of CCiX gates, which applies $-iX$ controlled on two control qubits [[1212.5069](https://arxiv.org/abs/1212.5069)].
|
|
352
|
+
|
|
353
|
+
### Measurement operations
|
|
354
|
+
|
|
355
|
+
[//]: # "physicalCountsFormatted/logicalCountsMeasurementCount"
|
|
356
|
+
|
|
357
|
+
_Number of single qubit measurements in the input quantum program_
|
|
358
|
+
|
|
359
|
+
This is the number of single qubit measurements in Pauli basis that are used in the input program. Note that all measurements are counted, however, the measurement result is is determined randomly (with a fixed seed) to be 0 or 1 with a probability of 50%.
|
|
360
|
+
|
|
361
|
+
## Assumed error budget
|
|
362
|
+
|
|
363
|
+
### Total error budget
|
|
364
|
+
|
|
365
|
+
[//]: # "physicalCountsFormatted/errorBudget"
|
|
366
|
+
|
|
367
|
+
_Total error budget for the algorithm_
|
|
368
|
+
|
|
369
|
+
The total error budget sets the overall allowed error for the algorithm, i.e., the number of times it is allowed to fail. Its value must be between 0 and 1 and the default value is 0.001, which corresponds to 0.1%, and means that the algorithm is allowed to fail once in 1000 executions. This parameter is highly application specific. For example, if one is running Shor's algorithm for factoring integers, a large value for the error budget may be tolerated as one can check that the output are indeed the prime factors of the input. On the other hand, a much smaller error budget may be needed for an algorithm solving a problem with a solution which cannot be efficiently verified. This budget $\epsilon = \epsilon_{\log} + \epsilon_{\rm dis} + \epsilon_{\rm syn}$ is uniformly distributed and applies to errors $\epsilon_{\log}$ to implement logical qubits, an error budget $\epsilon_{\rm dis}$ to produce T states through distillation, and an error budget $\epsilon_{\rm syn}$ to synthesize rotation gates with arbitrary angles. Note that for distillation and rotation synthesis, the respective error budgets $\epsilon_{\rm dis}$ and $\epsilon_{\rm syn}$ are uniformly distributed among all T states and all rotation gates, respectively. If there are no rotation gates in the input algorithm, the error budget is uniformly distributed to logical errors and T state errors.
|
|
370
|
+
|
|
371
|
+
### Logical error probability
|
|
372
|
+
|
|
373
|
+
[//]: # "physicalCountsFormatted/errorBudgetLogical"
|
|
374
|
+
|
|
375
|
+
_Probability of at least one logical error_
|
|
376
|
+
|
|
377
|
+
This is one third of the total error budget `physicalCountsFormatted/errorBudget` if the input algorithm contains rotation with gates with arbitrary angles, or one half of it, otherwise.
|
|
378
|
+
|
|
379
|
+
### T distillation error probability
|
|
380
|
+
|
|
381
|
+
[//]: # "physicalCountsFormatted/errorBudgetTstates"
|
|
382
|
+
|
|
383
|
+
_Probability of at least one faulty T distillation_
|
|
384
|
+
|
|
385
|
+
This is one third of the total error budget `physicalCountsFormatted/errorBudget` if the input algorithm contains rotation with gates with arbitrary angles, or one half of it, otherwise.
|
|
386
|
+
|
|
387
|
+
### Rotation synthesis error probability
|
|
388
|
+
|
|
389
|
+
[//]: # "physicalCountsFormatted/errorBudgetRotations"
|
|
390
|
+
|
|
391
|
+
_Probability of at least one failed rotation synthesis_
|
|
392
|
+
|
|
393
|
+
This is one third of the total error budget `physicalCountsFormatted/errorBudget`.
|
|
394
|
+
|
|
395
|
+
## Physical qubit parameters
|
|
396
|
+
|
|
397
|
+
_Info:_ Note that not all values are shown depending on the instruction set of the qubit parameters.
|
|
398
|
+
|
|
399
|
+
### Qubit name
|
|
400
|
+
|
|
401
|
+
[//]: # "jobParams/qubitParams/name"
|
|
402
|
+
|
|
403
|
+
_Some descriptive name for the qubit model_
|
|
404
|
+
|
|
405
|
+
You can load pre-defined qubit parameters by using the names `qubit_gate_ns_e3`, `qubit_gate_ns_e4`, `qubit_gate_us_e3`, `qubit_gate_us_e4`, `qubit_maj_ns_e4`, or `qubit_maj_ns_e6`. The names of these pre-defined qubit parameters indicate the instruction set (gate-based or Majorana), the operation speed (ns or µs regime), as well as the fidelity (e.g., e3 for $10^{-3}$ gate error rates).
|
|
406
|
+
|
|
407
|
+
### Instruction set
|
|
408
|
+
|
|
409
|
+
[//]: # "jobParams/qubitParams/instructionSet"
|
|
410
|
+
|
|
411
|
+
_Underlying qubit technology (gate-based or Majorana)_
|
|
412
|
+
|
|
413
|
+
When modeling the physical qubit abstractions, we distinguish between two different physical instruction sets that are used to operate the qubits. The physical instruction set can be either _gate-based_ or _Majorana_. A gate-based instruction set provides single-qubit measurement, single-qubit gates (incl. T gates), and two-qubit gates. A Majorana instruction set provides a physical T gate, single-qubit measurement and two-qubit joint measurement operations.
|
|
414
|
+
|
|
415
|
+
### Single-qubit measurement time
|
|
416
|
+
|
|
417
|
+
[//]: # "jobParams/qubitParams/oneQubitMeasurementTime"
|
|
418
|
+
|
|
419
|
+
_Operation time for single-qubit measurement (t_meas) in ns_
|
|
420
|
+
|
|
421
|
+
This is the operation time in nanoseconds to perform a single-qubit measurement in the Pauli basis.
|
|
422
|
+
|
|
423
|
+
### Two-qubit measurement time
|
|
424
|
+
|
|
425
|
+
[//]: # "jobParams/qubitParams/twoQubitJointMeasurementTime"
|
|
426
|
+
|
|
427
|
+
_Operation time for two-qubit measurement in ns_
|
|
428
|
+
|
|
429
|
+
This is the operation time in nanoseconds to perform a non-destructive two-qubit joint Pauli measurement.
|
|
430
|
+
|
|
431
|
+
### Single-qubit gate time
|
|
432
|
+
|
|
433
|
+
[//]: # "jobParams/qubitParams/oneQubitGateTime"
|
|
434
|
+
|
|
435
|
+
_Operation time for single-qubit gate (t_gate) in ns_
|
|
436
|
+
|
|
437
|
+
This is the operation time in nanoseconds to perform a single-qubit Clifford operation, e.g., Hadamard or Phase gates.
|
|
438
|
+
|
|
439
|
+
### Two-qubit gate time
|
|
440
|
+
|
|
441
|
+
[//]: # "jobParams/qubitParams/twoQubitGateTime"
|
|
442
|
+
|
|
443
|
+
_Operation time for two-qubit gate in ns_
|
|
444
|
+
|
|
445
|
+
This is the operation time in nanoseconds to perform a two-qubit Clifford operation, e.g., a CNOT or CZ gate.
|
|
446
|
+
|
|
447
|
+
### T gate time
|
|
448
|
+
|
|
449
|
+
[//]: # "jobParams/qubitParams/tGateTime"
|
|
450
|
+
|
|
451
|
+
_Operation time for a T gate_
|
|
452
|
+
|
|
453
|
+
This is the operation time in nanoseconds to execute a T gate.
|
|
454
|
+
|
|
455
|
+
### Single-qubit measurement error rate
|
|
456
|
+
|
|
457
|
+
[//]: # "jobParams/qubitParams/oneQubitMeasurementErrorRate"
|
|
458
|
+
|
|
459
|
+
_Error rate for single-qubit measurement_
|
|
460
|
+
|
|
461
|
+
This is the probability in which a single-qubit measurement in the Pauli basis may fail.
|
|
462
|
+
|
|
463
|
+
### Two-qubit measurement error rate
|
|
464
|
+
|
|
465
|
+
[//]: # "jobParams/qubitParams/twoQubitJointMeasurementErrorRate"
|
|
466
|
+
|
|
467
|
+
_Error rate for two-qubit measurement_
|
|
468
|
+
|
|
469
|
+
This is the probability in which a non-destructive two-qubit joint Pauli measurement may fail.
|
|
470
|
+
|
|
471
|
+
### Single-qubit error rate
|
|
472
|
+
|
|
473
|
+
[//]: # "jobParams/qubitParams/oneQubitGateErrorRate"
|
|
474
|
+
|
|
475
|
+
_Error rate for single-qubit Clifford gate (p)_
|
|
476
|
+
|
|
477
|
+
This is the probability in which a single-qubit Clifford operation, e.g., Hadamard or Phase gates, may fail.
|
|
478
|
+
|
|
479
|
+
### Two-qubit error rate
|
|
480
|
+
|
|
481
|
+
[//]: # "jobParams/qubitParams/twoQubitGateErrorRate"
|
|
482
|
+
|
|
483
|
+
_Error rate for two-qubit Clifford gate_
|
|
484
|
+
|
|
485
|
+
This is the probability in which a two-qubit Clifford operation, e.g., CNOT or CZ gates, may fail.
|
|
486
|
+
|
|
487
|
+
### T gate error rate
|
|
488
|
+
|
|
489
|
+
[//]: # "jobParams/qubitParams/tGateErrorRate"
|
|
490
|
+
|
|
491
|
+
_Error rate to prepare single-qubit T state or apply a T gate (p_T)_
|
|
492
|
+
|
|
493
|
+
This is the probability in which executing a single T gate may fail.
|
|
494
|
+
|
|
495
|
+
## Constraints
|
|
496
|
+
|
|
497
|
+
### Logical depth factor
|
|
498
|
+
|
|
499
|
+
[//]: # "physicalCountsFormatted/logicalDepthFactor"
|
|
500
|
+
|
|
501
|
+
_Factor, the initial number of logical cycles is multiplied by_
|
|
502
|
+
|
|
503
|
+
This is the factor takes into account a potential overhead to the initial number of logical cycles.
|
|
504
|
+
|
|
505
|
+
### Maximum number of T factories
|
|
506
|
+
|
|
507
|
+
[//]: # "physicalCountsFormatted/maxTFactories"
|
|
508
|
+
|
|
509
|
+
_The maximum number of T factories can be utilized during the algorithm's runtime_
|
|
510
|
+
|
|
511
|
+
This is the maximum number of T factories used for producing the demanded T states, which can be created and executed by the algorithm in parallel.
|
|
512
|
+
|
|
513
|
+
### Maximum runtime duration
|
|
514
|
+
|
|
515
|
+
[//]: # "physicalCountsFormatted/maxDuration"
|
|
516
|
+
|
|
517
|
+
_The maximum runtime duration allowed for the algorithm runtime_
|
|
518
|
+
|
|
519
|
+
This is the maximum time allowed to the algorithm. If specified, the estimator targets to minimize the number of physical qubits consumed by the algorithm for runtimes under the maximum allowed.
|
|
520
|
+
|
|
521
|
+
### Maximum number of physical qubits
|
|
522
|
+
|
|
523
|
+
[//]: # "physicalCountsFormatted/maxPhysicalQubits"
|
|
524
|
+
|
|
525
|
+
_The maximum number of physical qubits allowed for utilization to the algorithm_
|
|
526
|
+
|
|
527
|
+
This is the maximum number of physical qubits available to the algorithm. If specified, the estimator targets to minimize the runtime of the algorithm with number of physical qubits consumed not exceeding this maximum.
|
|
528
|
+
|
|
529
|
+
## Assumptions
|
|
530
|
+
|
|
531
|
+
- _More details on the following lists of assumptions can be found in the paper [Accessing requirements for scaling quantum computers and their applications](https://aka.ms/AQ/RE/Paper)._
|
|
532
|
+
- **Uniform independent physical noise.** We assume that the noise on physical qubits and physical qubit operations is the standard circuit noise model. In particular we assume error events at different space-time locations are independent and that error rates are uniform across the system in time and space.
|
|
533
|
+
- **Efficient classical computation.** We assume that classical overhead (compilation, control, feedback, readout, decoding, etc.) does not dominate the overall cost of implementing the full quantum algorithm.
|
|
534
|
+
- **Extraction circuits for planar quantum ISA.** We assume that stabilizer extraction circuits with similar depth and error correction performance to those for standard surface and Hastings-Haah code patches can be constructed to implement all operations of the planar quantum ISA (instruction set architecture).
|
|
535
|
+
- **Uniform independent logical noise.** We assume that the error rate of a logical operation is approximately equal to its space-time volume (the number of tiles multiplied by the number of logical time steps) multiplied by the error rate of a logical qubit in a standard one-tile patch in one logical time step.
|
|
536
|
+
- **Negligible Clifford costs for synthesis.** We assume that the space overhead for synthesis and space and time overhead for transport of magic states within magic state factories and to synthesis qubits are all negligible.
|
|
537
|
+
- **Smooth magic state consumption rate.** We assume that the rate of T state consumption throughout the compiled algorithm is almost constant, or can be made almost constant without significantly increasing the number of logical time steps for the algorithm.
|
package/ux/qsharp-ux.css
CHANGED
|
@@ -615,3 +615,40 @@ html {
|
|
|
615
615
|
fill: var(--vscode-icon-foreground, gray);
|
|
616
616
|
animation: codicon-spin 1.5s steps(45) infinite;
|
|
617
617
|
}
|
|
618
|
+
|
|
619
|
+
.qs-scatterChart {
|
|
620
|
+
font-size: 14px;
|
|
621
|
+
}
|
|
622
|
+
|
|
623
|
+
.qs-scatterChart-x-axisTitle,
|
|
624
|
+
.qs-scatterChart-y-axisTitle {
|
|
625
|
+
text-anchor: middle;
|
|
626
|
+
font-size: 16px;
|
|
627
|
+
fill: var(--main-color);
|
|
628
|
+
}
|
|
629
|
+
|
|
630
|
+
.qs-scatterChart-y-axisTitle {
|
|
631
|
+
writing-mode: vertical-lr;
|
|
632
|
+
transform: rotate(180deg);
|
|
633
|
+
}
|
|
634
|
+
|
|
635
|
+
.qs-scatterChart-line {
|
|
636
|
+
stroke: var(--border-color);
|
|
637
|
+
}
|
|
638
|
+
|
|
639
|
+
.qs-scatterChart-point {
|
|
640
|
+
r: 2px;
|
|
641
|
+
stroke-width: 4px;
|
|
642
|
+
}
|
|
643
|
+
|
|
644
|
+
.qs-scatterChart-point-selected,
|
|
645
|
+
.qs-scatterChart-point:hover {
|
|
646
|
+
r: 6px;
|
|
647
|
+
stroke-width: 3px;
|
|
648
|
+
fill: white;
|
|
649
|
+
}
|
|
650
|
+
|
|
651
|
+
.qs-scatterChart-watermark {
|
|
652
|
+
font-size: 16px;
|
|
653
|
+
fill: var(--main-color);
|
|
654
|
+
}
|
package/ux/reTable.tsx
CHANGED
|
@@ -2,41 +2,20 @@
|
|
|
2
2
|
// Licensed under the MIT License.
|
|
3
3
|
|
|
4
4
|
import { useState } from "preact/hooks";
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
status: string;
|
|
8
|
-
jobParams: any;
|
|
9
|
-
physicalCounts: any;
|
|
10
|
-
physicalCountsFormatted: any;
|
|
11
|
-
logicalQubit: any;
|
|
12
|
-
tfactory: any;
|
|
13
|
-
errorBudget: any;
|
|
14
|
-
logicalCounts: any;
|
|
15
|
-
reportData: {
|
|
16
|
-
groups: {
|
|
17
|
-
title: string;
|
|
18
|
-
alwaysVisible: boolean;
|
|
19
|
-
entries: {
|
|
20
|
-
path: string;
|
|
21
|
-
label: string;
|
|
22
|
-
description: string;
|
|
23
|
-
explanation: string;
|
|
24
|
-
}[];
|
|
25
|
-
}[];
|
|
26
|
-
assumptions: string[];
|
|
27
|
-
};
|
|
28
|
-
new: boolean;
|
|
29
|
-
};
|
|
5
|
+
import { SingleEstimateResult } from "./data.js";
|
|
6
|
+
import { CreateReport } from "./report.js";
|
|
30
7
|
|
|
31
8
|
export function ReTable(props: {
|
|
32
9
|
mdRenderer: (input: string) => string;
|
|
33
|
-
estimatesData:
|
|
10
|
+
estimatesData: SingleEstimateResult;
|
|
34
11
|
}) {
|
|
35
12
|
const [showDetail, setShowDetail] = useState(false);
|
|
36
13
|
const toggleDetail = () => {
|
|
37
14
|
setShowDetail(!showDetail);
|
|
38
15
|
};
|
|
39
16
|
|
|
17
|
+
const reportData = CreateReport(props.estimatesData);
|
|
18
|
+
|
|
40
19
|
return (
|
|
41
20
|
<div>
|
|
42
21
|
<div>
|
|
@@ -48,7 +27,7 @@ export function ReTable(props: {
|
|
|
48
27
|
/>
|
|
49
28
|
<label htmlFor="showDetail"> Show detailed rows</label>
|
|
50
29
|
</div>
|
|
51
|
-
{
|
|
30
|
+
{reportData.groups.map((group) => {
|
|
52
31
|
return (
|
|
53
32
|
<details className="estimate-details">
|
|
54
33
|
<summary>
|
|
@@ -101,7 +80,7 @@ export function ReTable(props: {
|
|
|
101
80
|
<strong>Assumptions</strong>
|
|
102
81
|
</summary>
|
|
103
82
|
<ul className="estimate-table">
|
|
104
|
-
{
|
|
83
|
+
{reportData.assumptions.map((assumption) => (
|
|
105
84
|
<li
|
|
106
85
|
className="estimate-assumption"
|
|
107
86
|
dangerouslySetInnerHTML={{ __html: props.mdRenderer(assumption) }}
|