mirror of https://github.com/openqasm/openqasm.git
commit
229212fad2
|
@ -291,7 +291,7 @@ iterations of the loop ``body``. ``values`` can be:
|
|||
an alias to classical bits. The corresponding scalar type of the loop
|
||||
variable is ``bit``, as appropriate.
|
||||
|
||||
- a value of type ``array[<scalar>, n]``, _i.e._ a one-dimensional
|
||||
- a value of type ``array[<scalar>, n]``, *i.e.* a one-dimensional
|
||||
array. Values of type ``scalar`` must be able to be implicitly promoted to
|
||||
values of type ``type``. Modification of the loop variable does not change
|
||||
the corresponding value in the array.
|
||||
|
|
|
@ -8,7 +8,7 @@ Initialization
|
|||
|
||||
The statement ``reset qubit|qubit[];`` resets a qubit or quantum register to the state
|
||||
:math:`|0\rangle`. This corresponds to a partial trace over those qubits
|
||||
(i.e. discarding them) before replacing them with
|
||||
(*i.e.* discarding them) before replacing them with
|
||||
:math:`|0\rangle\langle 0|`. Reset is shown in :numref:`fig_prepare`.
|
||||
|
||||
.. code-block::
|
||||
|
|
|
@ -92,12 +92,12 @@ frame of a Hamiltonian, throughout the execution of a program. Openpulse provide
|
|||
|
||||
- Tracking time appropriately so programs do not need to deal in absolute time or with the
|
||||
bookkeeping of advancing time in a sequence of pulses.
|
||||
- Tracking accrued phase by producing a complex value given an input time (i.e. via the mathematical
|
||||
- Tracking accrued phase by producing a complex value given an input time (*i.e.* via the mathematical
|
||||
relationship :math:`e^{i\left(2\pi f t + \theta\right)}`, where `f` is frequency and
|
||||
:math:`\theta` is the accrued phase). In this way, a ``frame`` type behaves analogously to
|
||||
a `numerically-controlled oscillator (NCO) <https://en.wikipedia.org/wiki/Numerically-controlled_oscillator>`_).
|
||||
One motivation for keeping track of accrued phase is to allow pulses to be defined in the rotating frame with the
|
||||
effect being an equivalent application in the lab frame (i.e. with the carrier supplied by the ``frame``).
|
||||
effect being an equivalent application in the lab frame (*i.e.* with the carrier supplied by the ``frame``).
|
||||
Another motivation is to more naturally implement a "virtual Z-gate", which does not require a physical pulse but
|
||||
rather shifts the phase of all future pulses on that frame.
|
||||
|
||||
|
@ -327,9 +327,9 @@ only appear inside a ``defcal`` block and have two required parameters:
|
|||
- The frame to use for the pulse.
|
||||
- A value of type ``waveform`` representing the waveform envelope.
|
||||
|
||||
Here, the ``frame`` provides the time at which the ``waveform`` envelope is scheduled (i.e. via
|
||||
the frame's current ``time``), its carrier frequency (i.e. via the frames current ``frequency``),
|
||||
and its phase offset (i.e. via the frame's current ``phase``).
|
||||
Here, the ``frame`` provides the time at which the ``waveform`` envelope is scheduled (*i.e.* via
|
||||
the frame's current ``time``), its carrier frequency (*i.e.* via the frames current ``frequency``),
|
||||
and its phase offset (*i.e.* via the frame's current ``phase``).
|
||||
|
||||
.. code-block:: openpulse
|
||||
|
||||
|
@ -798,7 +798,7 @@ an acousto-optic deflector (AOD). The EOMs put sidebands on the laser light whil
|
|||
the light in an amount proportional to the frequency of the RF drive. This example was chosen
|
||||
because it is similar in spirit to the work by Levine et al._:cite:`levine2019` except that phase
|
||||
control is exerted using virtual Z gates on the AODs -- requiring frame tracking of the qubit
|
||||
frequency yet application of a tone that maps to the qubit position (i.e. requires the use of a
|
||||
frequency yet application of a tone that maps to the qubit position (*i.e.* requires the use of a
|
||||
sideband).
|
||||
|
||||
The program aims to perform a Hahn echo sequence on q1, and a Ramsey sequence on q2 and q3.
|
||||
|
|
|
@ -168,7 +168,7 @@ hold over permutations of physical qubit labels. Thus, physical qubits cannot be
|
|||
compiler or hardware provider without opt-in from the programmer.
|
||||
|
||||
Note that while physical circuits require physical qubits, the converse need not be true. A circuit
|
||||
that would require routing or gate decomposition to run (i.e., does not have a ``defcal`` for every
|
||||
that would require routing or gate decomposition to run (*i.e.*, does not have a ``defcal`` for every
|
||||
operation in the circuit) would by definition not be a physical circuit. However, physical qubits
|
||||
can still be used in such circuits.
|
||||
|
||||
|
@ -857,7 +857,7 @@ Index sets and slicing
|
|||
Register concatenation and slicing
|
||||
----------------------------------
|
||||
|
||||
Two or more registers of the same type (i.e. classical or quantum) can
|
||||
Two or more registers of the same type (*i.e.* classical or quantum) can
|
||||
be concatenated to form a register of the same type whose size is the
|
||||
sum of the sizes of the individual registers. The concatenated register
|
||||
is a reference to the bits or qubits of the original registers. The
|
||||
|
@ -865,7 +865,7 @@ statement ``a ++ b`` denotes the concatenation of registers ``a`` and ``b``. A r
|
|||
be concatenated with any part of itself.
|
||||
|
||||
Classical and quantum registers can be indexed in a way that selects a
|
||||
subset of (qu)bits, i.e. by an index set. A register so indexed is
|
||||
subset of (qu)bits, *i.e.* by an index set. A register so indexed is
|
||||
interpreted as a register of the same type but with a different size.
|
||||
The register slice is a reference to the original register. A register
|
||||
cannot be indexed by an empty index set.
|
||||
|
|
Loading…
Reference in New Issue