JCZ transpiler revision #1

emlynsg · 2025-11-19T14:14:39Z

This commit introduces minor changes required to support interfacing with a brickwork transpiler (future "PR").
Changes include:

Additional namespace exports which are needed for brickwork
Changes from list/Iterable to Sequence types to match usage across JCZ and brickwork
Separation of j_commands which is used across both modules

mgarnier59

Looks good, thanks for the work!

Some of my comments span the original version that Thierry has done.

Two quick comments/questions:

the well-formedness check on patterns directly depend on the well-formedness of the circuit. Are we doing this here because it's not yet implemented for graphix Circuit? I think separating concerns is good.
I'm not clear on the JCZinstruction type. It seems to me that we would need only sequences of circuit instructions and sequences of JCZ so I don't understand why we would want to mix those.

Also I don't think we took into account the case of a CZ gate in the circuit (but I might be wrong on that point)

mgarnier59 · 2025-11-20T09:53:28Z

graphix_jcz_transpiler/jcz_transpiler.py

    ------
-        IllformedPatternError: if the pattern is ill-formed.
        InternalInstructionError: if the circuit contains internal _XC or _ZC instructions.
+        IllformedPatternError: if the circuit has underdefined instructions.


It's strange that an ill-formed circuit raises a pattern error.

Yes agreed. Fixed.

mgarnier59 · 2025-11-20T10:05:52Z

graphix_jcz_transpiler/jcz_transpiler.py



-def instruction_to_jcz(instr: JCZInstruction) -> Iterable[J | CZ]:
+def instruction_to_jcz(instr: JCZInstruction) -> Sequence[J | CZ]:


On line 263-264 (unchanged): I agree it's weird to have an explicit identity in a circuit. Formally we could always compile the identity into two Hadamard (hence J(0) o J(0)). Maybe comment that we explicitly remove identities? I don't think it's very important though.

Yes it's odd, but I think this is the easiest way to deal with it and keep consistent outputs from the functions. Happy to leave this as is.

mgarnier59 · 2025-11-20T10:09:58Z

graphix_jcz_transpiler/jcz_transpiler.py



-def instruction_to_jcz(instr: JCZInstruction) -> Iterable[J | CZ]:
+def instruction_to_jcz(instr: JCZInstruction) -> Sequence[J | CZ]:


Is this function not suppose to take circuit instructions to JCZ? Hence the type annotation has to be modified. From JCZInstruction to JCZInstruction | Instruction.

What I don't understand is why we want to allow feeding a JCZInstructionto this function since it's just the identity on these objects. Circuits shouldn't contain such instructions.

As a side remark, the case where the circuit explicitely contains a CZ gate is not taken into account (I believe)

JCZInstruction is already defined as the union Instruction | J.

Yes, so to go from the bottom:

CZ gates are not in Graphix (yet) so shouldn't be a problem. I will add them in if/when my PR is merged.

JCZInstruction is defined as J | CZ | Instruction, so yes it will be the identity on J and CZ inputs. It is general because the function is recursive (might input CNOT, decomposed to H CZ H, which goes through the instruction_list_to_jcz and each is then sent to instruction_to_jcz.) So yes the initial inputs should just be Instruction type, but since the function is used for intermediate steps the typing needs to be the union.

mgarnier59 · 2025-11-20T10:12:28Z

graphix_jcz_transpiler/jcz_transpiler.py

+    ]
+
+
 def transpile_jcz(circuit: Circuit) -> TranspileResult:


Comment for line 374: why do we expect the circuit to contain _XCor _ZC instructions?

We don't, but unfortunately the instructions _XC and _ZC exist in graphix (they are used internally by the original transpiler, so I hope they will disappear eventually).

mgarnier59 · 2025-11-20T10:18:12Z

.gitignore

maybe remove the . vscode that is local?

mgarnier59 · 2025-11-20T10:23:46Z

tests/test_jcz_transpiler.py

    transpiled.pattern.perform_pauli_measurements()
    transpiled.pattern.minimize_space()

    def simulate_and_measure() -> int:


In this test, I would add a comment saying what we are doing: since it's a circuit transpiled in JCZ, the pattern has causal flow so all measurement outcomes have probability 1/2 to occur (up to statistical fluctuations).

thierry-martinez · 2025-11-21T15:32:43Z

graphix_jcz_transpiler/jcz_transpiler.py

 def decompose_ccx(
    instr: instruction.CCX,
-) -> list[instruction.H | instruction.CNOT | instruction.RZ]:
+) -> Sequence[instruction.H | instruction.CNOT | instruction.RZ]:


We usually follow the convention of being as precise as possible in the returned datatype, so we prefer the type list over Sequence if the return value is a list. This practice is Python-specific. In a statically typed language without downcasting, it would make sense to hide the concrete data type in the interface for better encapsulation. In Python, since callers can freely treat the result as a list if it is one, the most helpful type annotation is the concrete type.

I will try to commit with this changed back, but I get typing issues.
Something to do with Sequences being covariant, and lists not being.
May be able to keep as lists but broaden their typing to JCZInstruction.

Could you share the type error messages?

It also adds ""List" is invariant -- see https://mypy.readthedocs.io/en/stable/common_issues.html#variance
Consider using "Sequence" instead, which is covariant"

I propose a fix in this commit. There were two issues:

instruction_list_to_jcz took a list even though it only needs an Iterable. If a function f is defined with a parameter l: list[A], that parameter is mutable, so it would be unsafe to call f with an argument of type list[B] with B a subtype of A: f could append any A to l, including values that are not of type B. That's why list is invariant. Iterable provides read-only access and is covariant; since list[B] is an Iterable[B], it is also an Iterable[A] when B is a subtype of A.

The return type of instruction_to_jcz was list[J | CZ] but some branches return list[J]. I changed the return type to Sequence[J | CZ] which is a common supertype of both list[J | CZ] and list[J]. Alternatively, list[J | CZ] | list[J] would also work.

Thanks Thierry. Makes sense to me. Based on your logic above, should we not use Sequence rather than Iterable for instruction_list_to_jcz?
(Update: Ignore this question, I slept on it and it makes complete sense you would maximise generality on inputs and specificity on outputs.)

thierry-martinez · 2025-11-21T15:34:17Z

graphix_jcz_transpiler/jcz_transpiler.py



-def instruction_to_jcz(instr: JCZInstruction) -> Iterable[J | CZ]:
+def instruction_to_jcz(instr: JCZInstruction) -> Sequence[J | CZ]:


JCZInstruction is already defined as the union Instruction | J.

thierry-martinez · 2025-11-21T15:36:21Z

graphix_jcz_transpiler/jcz_transpiler.py

+    ]
+
+
 def transpile_jcz(circuit: Circuit) -> TranspileResult:


We don't, but unfortunately the instructions _XC and _ZC exist in graphix (they are used internally by the original transpiler, so I hope they will disappear eventually).

…ation on larger patterns produced through Open Graphs.

Update the code for the latest Graphix master API. Disable Pauli preprocessing in `test_circuit_simulation_og` because it can break the flow (graphix#363), and `minimize_space` does not work well when no flow is available (graphix#157).

emlynsg · 2025-12-11T14:33:42Z

@thierry-martinez @mgarnier59 let's review again first thing next week. I can update with the changes to Graphix main once the CZ PR is merged - I think best to leave the J gate separate for now given the further changes that would be required for the qasm parser.

Emlyn Graham added 21 commits October 23, 2025 15:06

Added transpiler pathway via Open Graph representation

335e4d3

fixing mypy checks

94bea7d

fixing mypy checks

86b3701

fixing mypy checks

1b619c7

fixing mypy checks

70c5c8c

fixing mypy checks

af68b6e

added finalised open graph functionality

9e092d9

added finalised open graph functionality

f4b435d

updated README and transpilation method:

057a3e9

updated files to interface with brickwork

d02b16c

Added error messages to init

97ab84a

Changed typing for brickwork benefit

c513c43

tidy up

248ed5b

updating imports

c1d1d21

fixing imports

eeddaf9

fixing imports

b01f5f1

Fixing display of -0.0 in some cases.

3ca5c2c

Exposing error to share with brickwork.

9a5c69b

JCZ ready for team review.

4cdb31c

JCZ ready for team review.

509a2d9

fixed type hints

6d0907f

emlynsg requested a review from thierry-martinez November 19, 2025 16:15

emlynsg mentioned this pull request Nov 19, 2025

Initial brickwork transpiler PR qat-inria/graphix-brickwork-transpiler#1

Open

mgarnier59 reviewed Nov 20, 2025

View reviewed changes

thierry-martinez reviewed Nov 21, 2025

View reviewed changes

Emlyn Graham and others added 5 commits December 4, 2025 15:40

Working by transpiling through Open Graph. Still issue with CCX simul…

a417506

…ation on larger patterns produced through Open Graphs.

Pushing with CCX tests on to test.

95aeae0

Fix mypy

cc7dfbe

fixing minor things

9c0c709



		def instruction_to_jcz(instr: JCZInstruction) -> Iterable[J \| CZ]:
		def instruction_to_jcz(instr: JCZInstruction) -> Sequence[J \| CZ]:

JCZ transpiler revision #1

Are you sure you want to change the base?

JCZ transpiler revision #1

Uh oh!

Conversation

emlynsg commented Nov 19, 2025

Uh oh!

mgarnier59 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

emlynsg Dec 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

emlynsg commented Dec 11, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

emlynsg Dec 5, 2025 •

edited

Loading