Support parameterized circuits in QASM3 export#159
Open
spital wants to merge 1 commit into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes #146.
This moves the OpenQASM 3 export implementation out of
QuantumCircuitinto a dedicated exporter while keeping the publicQuantumCircuit::to_qasm3()API. It also adds support for exporting parameterized circuits by emitting symbolic parameters as OpenQASM 3input float[64]declarations.What changed
src/circuit/qasm3_exporter.hppand delegateQuantumCircuit::to_qasm3()to it.input float[64]declarations before registers and operations.stdgates.incglobals, and custom gate definitions emitted by the exporter.qregister export behavior.gphase).Known limitations
The current Qiskit C API exposes the number of circuit parameter symbols but not an iterator over their names, so the exporter derives parameter identifiers from the string form returned by
qk_param_str(). This supports normal symbolic parameters and expressions, but parameter names should be OpenQASM-identifier-like.Some expression forms emitted by Qiskit's parameter string representation, such as power expressions (
theta**2) or function calls (sin(theta)), are not currently round-trippable throughqiskit_qasm3_import. The exporter preserves the expression spelling instead of rewriting it to a form that may change semantics.Testing
make -C test/deps/qiskit ccmake -S test -B /tmp/qisk146-hermes-review60-buildcmake --build /tmp/qisk146-hermes-review60-build -j20ctest --test-dir /tmp/qisk146-hermes-review60-build --output-on-failure/tmp/qisk146-hermes-review60-build/test_driver test_circuitgit diff --check origin/main...HEADqiskit 2.4.1/qiskit-qasm3-import 0.6.0usingqiskit.qasm3.loads()for reserved-name conflicts, keyword/constant-name conflicts, classical-register conflicts, controlled-U definitions, and global phase output.AI assistance disclosure
I used Codex, Claude, and Hermes as AI assistants to help prototype, review, compare related approaches, and draft PR text. I manually reviewed the resulting diff, checked the live GitHub issue/PR state and unitaryHACK policy, refined the implementation, and ran the tests listed above locally. The PR is submitted with human oversight; any remaining mistakes are mine.