Glossary¶
This glossary records MQT Core’s preferred terms and the distinctions that matter to its public interfaces and compiler design. It is not a copy of the MLIR glossary. Upstream definitions are useful context, but MQT Core owns the meanings documented here.
Update this page in the same pull request when introducing or changing a public or potentially ambiguous term. Each new entry must name the preferred term, list accepted aliases, and be understandable without detailed knowledge of the implementation.
Abbreviations and names¶
- CDA¶
- Chair for Design Automation¶
Preferred term: Chair for Design Automation. Accepted abbreviation: CDA. A research chair at the Technical University of Munich that develops MQT Core together with MQSC.
- DD¶
- DDs¶
- decision diagram¶
- decision diagrams¶
Preferred term: decision diagram. Accepted abbreviations: DD and DDs for the plural. A graph representation that shares repeated substructures to store and manipulate quantum states and operations compactly.
- IR¶
- intermediate representation¶
Preferred term: intermediate representation. Accepted abbreviation: IR. A program representation used between a source language and final output so compiler analyses and transformations can operate on explicit structure.
- jeff¶
Preferred term: jeff. Accepted aliases: none. A structured, extensible interchange format for quantum programs.
jeffis a name, not an abbreviation, and is always written in lowercase.- LLVM¶
Preferred term: LLVM. Accepted aliases: none. The compiler infrastructure project on which MLIR is built. LLVM is the current project name; do not expand it as an abbreviation in MQT prose.
- MLIR¶
- Multi-Level Intermediate Representation¶
Preferred term: MLIR. Accepted expansion: Multi-Level Intermediate Representation. LLVM’s reusable infrastructure for building compilers with several interoperating abstraction levels.
- modular multiplier¶
Preferred term: modular multiplier. Accepted aliases: none. An arithmetic circuit that computes a product reduced modulo a specified integer.
- MQSC¶
- Munich Quantum Software Company¶
Preferred term: MQSC. Accepted expansion: Munich Quantum Software Company. The company develops MQT Core together with the Chair for Design Automation at TUM. Use the linked short name in prose; reserve the full legal name for copyright notices.
- MQSS¶
- Munich Quantum Software Stack¶
Preferred term: Munich Quantum Software Stack. Accepted abbreviation: MQSS. The Munich Quantum Valley compilation and runtime ecosystem that connects quantum software to local and remote quantum devices.
- MQT¶
- Munich Quantum Toolkit¶
Preferred term: Munich Quantum Toolkit. Accepted abbreviation: MQT. The open-source software toolkit of which MQT Core is the shared foundation.
- MQT Compiler Collection¶
Preferred term: MQT Compiler Collection. Accepted aliases: none. MQT Core’s framework for compiling, optimizing, and exchanging quantum programs through Python, C++, and the
mqt-cccommand-line driver.- MQV¶
- Munich Quantum Valley¶
Preferred term: Munich Quantum Valley. Accepted abbreviation: MQV. A Bavarian initiative that develops quantum computing research, technology, education, and infrastructure.
- OpenQASM¶
- Open Quantum Assembly Language¶
Preferred term: OpenQASM. Accepted expansion: Open Quantum Assembly Language. A versioned language for describing quantum programs. Include the major version when behavior depends on it.
- Pauli string¶
Preferred term: Pauli string. Accepted alias: Pauli product. A tensor product of single-qubit identity or Pauli X, Y, and Z operators.
- QASM¶
- quantum assembly language¶
Preferred term: quantum assembly language. Accepted abbreviation: QASM. A generic category of assembly-like languages for quantum programs. Do not use QASM as an alias for a specific OpenQASM version.
- QDMI¶
- Quantum Device Management Interface¶
Preferred term: Quantum Device Management Interface. Accepted abbreviation: QDMI. An interface for discovering quantum-device properties and submitting and controlling work without coupling software to one device implementation.
- QIR¶
- Quantum Intermediate Representation¶
Preferred term: Quantum Intermediate Representation. Accepted abbreviation: QIR. An LLVM-based representation and runtime interface for exchanging and executing quantum programs.
- TUM¶
- Technical University of Munich¶
Preferred term: Technical University of Munich. Accepted abbreviation: TUM. The university that hosts the Chair for Design Automation.
Compiler terms¶
- canonicalization¶
A semantics-preserving rewrite toward a simpler or preferred representation. Canonicalization is not a general optimization pipeline and must not depend on a particular downstream target.
- compilation seed¶
An optional seed that overrides MQT pass-local seeds during one compilation. It controls mapping, Pauli twirling, and numerical synthesis retries. Execution sampling uses a separate seed.
- compiled program¶
A serialized program with the target and payload specification used to compile it. Submission checks that the destination supports the same contract.
- compiler target¶
An immutable MQT description of the operations, topology, and properties that a compiler pipeline may use for one destination. It is a snapshot used for compilation, not a live device connection.
- conversion¶
A change between or within MLIR dialects, from one legal set of operations or types to another. Conversion can be partial or complete and is governed by a conversion target that states what is legal.
- conversion target¶
Preferred term: conversion target. Accepted aliases: none. The MLIR legality rules used by a dialect conversion. It is distinct from an MQT compiler target, which describes a compilation destination.
- dialect¶
A named family of related MLIR operations, types, attributes, and rules. A dialect lets one IR contain concepts from several abstraction levels without forcing them into one universal instruction set.
- dynamic¶
Known only while executing the compiled program or interacting with a target. A dynamic quantum allocation acquires resources during execution, even when its size is a compile-time constant.
- execution payload¶
The serialized program submitted for execution. This is distinct from the MLIR transform dialect’s payload IR. A payload format identifies its representation; execution capabilities state what that representation may contain for the selected target.
- export¶
A translation from MQT Core or MLIR into an external representation.
- import¶
A translation from an external representation into MQT Core or MLIR.
- legalization¶
The act of replacing or rejecting IR until every remaining operation and type satisfies a declared conversion target or target capability.
- linear semantics¶
- linear ownership¶
Preferred term: linear semantics. Accepted alias: linear ownership when discussing ownership transfers. Each quantum SSA value in valid QCO IR has exactly one use, including block arguments. Control-flow operations transfer ownership through their operands, region arguments, and results.
qco::verifyLinearitychecks this rule; ordinary MLIR type checking alone does not establish it. Linearity does not imply positional wire correspondence.- lowering¶
A transformation from a higher-level representation to one closer to the operations supported by a target. Lowering can use conversion, rewrites, or several passes; it does not imply one specific MLIR mechanism.
- operation¶
- op¶
Preferred term: operation. Accepted alias: op in code and compact technical prose. The basic unit of work and structure in MLIR. An operation has a name and can have inputs, results, attributes, and nested regions.
- operation capability¶
Preferred term: operation capability. Accepted aliases: none. A compiler target’s description of a supported operation, including its name, arity, parameters, placements, and optional calibration data. Represented by
CompilerTarget::OperationCapabilityin C++ andCompilerTarget.OperationCapabilityin Python. An MLIR operation is an IR instance, not this capability description.- pass¶
A procedure that inspects or changes IR while preserving the invariants declared by its input and output contracts. A pass normally runs as one step of a pass pipeline.
- payload¶
The program IR on which a transform, schedule, or target-specific action operates. Use a more specific term when the exact object, such as a function or circuit, matters.
- QC¶
MQT’s compatibility-oriented quantum-circuit dialect. QC uses reference semantics: operations act on qubit references rather than producing a new SSA value for each updated qubit state.
- QCO¶
MQT’s optimization-oriented quantum-circuit dialect. QCO uses value semantics: a quantum operation consumes input qubit values and produces output qubit values.
- QTensor¶
MQT’s dialect for one-dimensional collections of qubits used with QCO. Its operations preserve the linear ownership of the contained quantum values. Each slot retains its qubit identity: extraction borrows a qubit and insertion restores it to the same underlying slot. Gates can change its state.
- reference semantics¶
A model in which an operation changes an object reached through a stable reference. QC qubit operations use this model.
- rewrite pattern¶
A local rule that recognizes one IR shape and replaces or updates it. A pattern reports failure without changing IR when its input does not match.
- selected payload specification¶
The exact format, encoding, and effective execution capabilities selected for a compiled program. It does not describe every format accepted by a device.
- serialization¶
Preferred term: serialization. Accepted aliases: none. Encoding a program as bytes or writing that encoding to a file. Deserialization reads the encoding back into a program. Converting QCO to the
jeffMLIR dialect prepares a serializable program;JeffProgram.to_bytesandJeffProgram.writeserialize it.- static¶
Known while compiling the program. Static does not necessarily mean a C++ object with static storage duration. In
qc.staticandqco.static, it describes a known qubit identifier, not a known quantum state.- static gate count¶
Preferred term: static gate count. Accepted aliases: none. The number of gate operations in the entry-point IR. Each structured control-flow region is counted once, including every branch and loop body. Modifier bodies are not counted recursively, and barriers are excluded. This is not the number of gates executed at runtime or a count expanded through function calls.
- target environment¶
A compiler target paired with the selected payload specification for one compilation. It combines hardware facts with the selected output contract.
- translation¶
A change across the boundary between MLIR and a non-MLIR representation, such as OpenQASM text, QIR, or another external program model. Prefer conversion when both the source and destination are MLIR dialects.
- value semantics¶
A model in which an operation consumes input values and produces new output values. QCO uses this model to make quantum data flow explicit in SSA form.
Quantum benchmark terms¶
- benchmark instance¶
Preferred term: benchmark instance. Accepted alias: instance when the benchmark context is clear. One validated member of a benchmark family with every default resolved. It owns a logical output and an analytic or verification reference and can be used to generate a program or manifest.
- benchmark instance specification¶
- instance specification¶
Preferred term: benchmark instance specification. Accepted alias: instance specification when the benchmark context is clear. A strict JSON document that names a benchmark family and provides the parameters used to construct an instance. Input can omit documented defaults; the canonical form records every resolved default. It specifies configuration. It does not request program generation or execution.
- benchmark manifest¶
- manifest¶
Preferred term: benchmark manifest. Accepted alias: manifest when the benchmark context is clear. A canonical sidecar record generated for a benchmark instance. It records the resolved parameters, case ID, logical outputs, reference model, and benchmark-definition version. It accompanies the generated program but does not identify its file, format, or bytes.
- continued fraction¶
Preferred term: continued fraction. Accepted aliases: none. A nested representation of a number by integer parts and reciprocals. Truncations, called convergents, give rational approximations used to recover candidate exponents from measured phases in Shor’s algorithm.
- iterative quantum phase estimation¶
- iterative QPE¶
- iQPE¶
Preferred term: iterative quantum phase estimation. Accepted aliases: iterative QPE and iQPE. A phase-estimation method that measures, resets, and reuses one query qubit for each output bit. Each round applies corrections controlled by earlier measurement results.
- magic state¶
Preferred term: magic state. Accepted aliases: none. A non-stabilizer quantum state consumed by protocols that implement non-Clifford operations using Clifford operations and measurements. The distillation benchmark uses \(|T\rangle = T|+\rangle\).
- magic-state distillation¶
Preferred term: magic-state distillation. Accepted aliases: none. A protocol that consumes several imperfect magic states and conditionally retains fewer states with smaller errors. Concatenated levels feed retained quantum states into further blocks. The benchmark uses ideal inputs to check the protocol’s execution.
- order finding¶
Preferred term: order finding. Accepted aliases: none. Finding the smallest positive exponent \(r\) for which a given base \(a\) satisfies \(a^r \equiv 1 \pmod{N}\), with \(a\) coprime to \(N\).
- semiclassical quantum Fourier transform¶
- semiclassical QFT¶
Preferred term: semiclassical quantum Fourier transform. Accepted alias: semiclassical QFT. A quantum Fourier-transform method that measures, resets, and reuses one qubit for each output bit. Each round applies rotations controlled by earlier measurement results.
- Shor’s algorithm¶
Preferred term: Shor’s algorithm. Accepted alias: Shor when naming the benchmark family. A factoring algorithm that combines quantum order finding with classical arithmetic to recover and verify nontrivial factors.
- W state¶
Preferred term: W state. The equal, positive-amplitude superposition of all computational-basis states with exactly one qubit in state one.
Index¶
Every glossary entry appears in the alphabetical documentation index.