Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

qodec-to-deq conversion : Pauli frame lost across ZZ parity measurement

Open
  • Is something wrong?
#3,980 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
47/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
python
Domain
backend, testing

Research direction

Start with _action_propagations in source/qdk_package/qdk/simulation/_qodec/deq_conversion.py and inspect how it maps incoming frame components across a nondestructive ZZ measurement. Run the attached repro.py with the pinned requirements; it should currently fail with the reported assertion. Done means the corrected readout XORs are all 1 while the qodec audit still passes.

Written by the indexing model from the issue text.

Description

bug needs triage

Describe the bug

QDK's qodec-to-deq adapter loses an incoming Pauli-frame correction across a nondestructive ZZ measurement. This produces an incorrect final XX parity at zero noise, using only two unencoded qubits.

To Reproduce

  1. Extract the attached joint-frame-repro.zip and open a terminal in the
    extracted directory.

  2. Create a fresh environment and install the pinned released packages from
    PyPI. With Python 3.14 on Windows:

    py -3.14 -m venv .venv
.\.venv\Scripts\python.exe -m pip install -r .\requirements.txt
.\.venv\Scripts\python.exe -m pip check

  3. Run the attached script with that environment's interpreter:

    .\.venv\Scripts\python.exe -B .\repro.py

The qodec passes ec.audit(..., promote_warnings=True). The experiment prints:

Final X-readout XORs: [0, 0, 0, 0, 0, 0, 0, 0]

It then raises AssertionError: Incoming Z frame was lost across the ZZ measurement.
This assertion, not an import/build/runtime error, is the expected reproduction.

Expected behavior

Every final XOR should be 1:

  1. prepare prepares each qubit in the +1 eigenstate of X.
  2. frame(a) implements logical Z on A through a classical frame update only:
    its physical circuit is empty, and its outgoing X-sign frame contribution is 1.
    The interpreted state therefore has XX eigenvalue -1.
  3. joint physically measures ZZ without discarding either qubit. Since
    $[Z_A Z_B, X_A X_B]=0$, the XX eigenvalue must remain -1.
  4. read measures each qubit in X and incorporates its incoming frame.
    Their corrected readout bits must have XOR 1.

Removing only the joint-measurement call restores the correct XOR of 1.
Removing only the frame update gives the expected XOR of 0.

System information

  • OS: Windows 11
  • Architecture: ARM64
  • Python: x86-64 Python 3.14.7 (win-amd64, under emulation)
  • QDK: 1.33.1, official PyPI Windows wheel.
  • qodec: 0.2.1; deq: 0.5.16; deq-runtime: 0.5.16; Stim: 1.16.0.
  • paulimer: 0.2.9; binar: 0.1.8.

Additional context

The suspect routine is
_action_propagations.
For this ZZ gadget it returns no incoming contribution for either outgoing X-sign
component. In the ordering (x_A, z_A, x_B, z_B), its map is
(0, 0, 0, z_A XOR z_B), whereas the incoming frame should survive the
nondestructive Pauli observation. Our input (1, 0, 0, 0) is consequently lost.

joint-frame-repro.zip

Dominant language
Rust
Stars
1k
Forks
219
Avg merge
4d 1h
Merged PRs (30d)
88

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/qdk

All issues in microsoft/qdk

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.