Quantum Process

Every operation in Ket is tied to a quantum process. The process holds all the necessary information about the quantum circuit and the target quantum execution backend. In Ket, a process is instantiated using the Process class. By default, the process sends the quantum execution to KBW using a sparse simulator limited to 32 qubits. Optional arguments can be passed to configure KBW or to designate other execution targets.

From the programmer’s perspective, the primary role of the process is to allocate qubits for execution using the alloc method, which allocates n qubits. These qubits are exposed to the programmer encapsulated within a Quant object, which acts as a list of opaque references to the underlying qubits. Many standard Python list operations are available for Quant objects, including indexing, slicing, concatenation, and iteration. Even when a qubit is individually indexed, it remains encapsulated within a Quant.

process = Process()       # Creating a process with default arguments.
qubits = process.alloc(n) # Allocating n qubits.

The use of opaque references means that each qubit variable in Ket does not hold the raw quantum information itself, but merely points to it. This design mitigates the need for the programmer or the platform to handle the no-cloning theorem; copying a qubit variable simply copies the classical reference, not the underlying quantum state.

Ket is intrinsically designed to support two distinct quantum execution modes. However, the specific mode utilized during a program’s runtime depends entirely on the capabilities and requirements of the target quantum execution backend. The modes are:

  • Batch: In this paradigm, the target quantum device operates similarly to a traditional batch-job scheduler. The complete quantum circuit is constructed by the classical Python host and submitted to the backend as a single, indivisible job. Consequently, the quantum execution cannot be preempted or paused, meaning that classical control flow (such as if/else branching) cannot dynamically depend on intermediate quantum measurement results.

  • Live: This paradigm enables real-time, dynamic interaction between the classical host and the quantum execution backend. The quantum state coherence is maintained while intermediate measurement results are returned to the classical program. This facilitates dynamic, on-the-fly circuit generation and algorithms that strictly require mid-circuit measurements and classical feed-forward operations. While quantum hardware supporting the live mode currently remains limited, this mode provides an essential simulation environment for researching quantum error correction [4] and dynamic quantum circuits.

When instantiating the Process class, the programmer can configure the underlying backend. The default KBW simulator natively supports both execution modes and accepts optional keyword arguments to fine-tune the simulation environment:

  • execution: Explicitly dictates the execution mode for the simulator, accepting either "live" (the default) or "batch".

  • simulator: Specifies the internal state-vector simulation algorithm. It accepts either "sparse" (the default) or "dense".

  • num_qubits: Defines the maximum capacity of qubits available for allocation. If omitted, this defaults to 32 qubits for the sparse and 12 qubits for the dense simulator.

  • gradient: A boolean flag (defaulting to False) that instructs the runtime library to enable automatic gradient computation for parameterized quantum circuits.