Refactor of flow tools - `OpenGraph.isclose` by matulni · Pull Request #374 · TeamGraphix/graphix

matulni · 2025-11-25T09:16:29Z

This commit adapts the existing method :func: OpenGraph.isclose to the new API introduced in #358.
Additionally, it introduces a new method :func: OpenGraph.__eq__ relevant for open graphs of parametric type graphix.fundamentals.Plane or graphix.fundamentals.Axis.

codecov · 2025-11-25T09:20:10Z

Codecov Report

❌ Patch coverage is 61.11111% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.30%. Comparing base (8d9a477) to head (9358992).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
graphix/opengraph.py	36.36%	7 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #374      +/-   ##
==========================================
+ Coverage   86.25%   86.30%   +0.05%     
==========================================
  Files          44       44              
  Lines        6161     6162       +1     
==========================================
+ Hits         5314     5318       +4     
+ Misses        847      844       -3

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

graphix/opengraph.py

thierry-martinez · 2025-11-25T14:45:45Z

graphix/opengraph.py

+    if og_1.input_nodes != og_2.input_nodes or og_1.output_nodes != og_2.output_nodes:
+        return False
+
+    return set(og_1.measurements.keys()) == set(og_2.measurements.keys())


Isn't it redundant? If both og_1 and og_2 are well-formed, then these keys are their non-output nodes, and we already know that the two graphs have the same nodes and the same output nodes.

Yes, in a context where we don't allow incorrect open graphs, this is redundant. However, I thought that we were moving away from this model, i.e., substituting the post_init by a check_well_formed method. Anticipating this design, I thought it might be interesting to ensure that two open graphs are equal, even if they are not correct (for debugging purposes, mainly). If you think the sacrifice in readability and efficiency is not worth, I'm ok with suppressing the check on the measured nodes.

Okay, if the plan is to move towards allowing incorrect open graphs to be constructed and possibly checked afterwards, it makes sense to have a comparison function that even works on incorrect graphs.

Hi again @thierry-martinez. When writing #381 and #378 I realised that it's quite practical to assume that open graphs are well formed. I propose that we keep (at least for now) the _post_init_ design pattern for open graphs.

I think that for open graphs this is justified because open graphs are more often input directly by the user (contrary to flow objects, which result from built-in generation routines).

In 5cd51d6, I removed the redundancy in the structural comparison of (well-formed) open graphs as you suggested.

thierry-martinez · 2025-11-25T14:47:56Z

graphix/opengraph.py

+    if not nx.utils.graphs_equal(og_1.graph, og_2.graph):
+        return False
+
+    if og_1.input_nodes != og_2.input_nodes or og_1.output_nodes != og_2.output_nodes:
+        return False


Suggested change

if not nx.utils.graphs_equal(og_1.graph, og_2.graph):

return False

if og_1.input_nodes != og_2.input_nodes or og_1.output_nodes != og_2.output_nodes:

return False

return (

nx.utils.graphs_equal(og_1.graph, og_2.graph)

and og_1.input_nodes == og_2.input_nodes

and og_1.output_nodes == og_2.output_nodes

)

graphix/opengraph.py

tests/test_opengraph.py

thierry-martinez

LGTM! All the changes in this PR are included in #375, right? In that case, you can either merge this PR first and then #375, or just drop this PR and merge only #375. I would say it mainly depends on which PR receives the second approval first!

matulni · 2025-12-02T10:16:34Z

Implemented minor modification from discussion in 9358992
@mgarnier59

emlynsg

LGTM too!

This commit adapts the existing method `graphix.opengraph.OpenGraph.isclose` to the new API introduced in #358. Additionally, it introduces the new methods `graphix.opengraph.OpenGraph.is_equal_structurally` which compares the underlying structure of two open graphs, and `graphix.fundamentals.AbstractMeasurement.isclose` which defaults to `==` comparison.

* trying to remove BackendState still causing problems * trying to remove BackendState bad fixed version * Fixing typing. * Fixed typing after removing backend state. * Introduce `BaseN` and `PrepareMethod` (#383) This commit introduces the classes `BaseN` and `PrepareMethod`, which allow the user to customize how `N` commands are handled. For instance, in the VBQC context of Veriphix, `N` commands do not necessarily prepare the node in the |+> state: for each prepared qubit, the preparation should be performed by the client, so that the server does not even see the state. * trying to remove BackendState still causing problems * Refactor of flow tools - `OpenGraph.isclose` (#374) This commit adapts the existing method `graphix.opengraph.OpenGraph.isclose` to the new API introduced in #358. Additionally, it introduces the new methods `graphix.opengraph.OpenGraph.is_equal_structurally` which compares the underlying structure of two open graphs, and `graphix.fundamentals.AbstractMeasurement.isclose` which defaults to `==` comparison. * Refactor of flow tools - `OpenGraph.compose` (#375) This commit adapts the existing method `:func: OpenGraph.compose` to the new API introduced in #358. * Fix #349: ensure flow for patterns transpiled from circuit (#362) This commit fixes domains in the transpiler so that every pattern transpiled from a circuit has a flow. Previously, some domains were incompatible with any flow, despite the patterns being deterministic, because some measurement angles were zero, causing the measurements to ignore certain signals. This commit also adds `optimization.remove_useless_domains` to remove the domains ignored by measurements with angle zero, to recover the same "optimized" patterns as before when needed. This commit also adds `rand_state_vector` to draw a random state vector. * Fixing typing. * Refactor of flow tools - Verification of flow objects (#378) This PR introduces the methods `:func: PauliFlow.check_well_formed`, `:func: GFlow.check_well_formed` and `:func: CausalFlow.check_well_formed` which verify the correctness of flow objects and raise exceptions when the flow is incorrect. Exception classes are grouped in the new module `graphix.flow.exceptions`. The error messages explain which proposition in the flow is violated. Flow-finding algorithms always (in principle) output well-formed flows, but it is possible to instantiate flow objects by passing arbitrary parameters to the constructors. In such cases, there is not any guarantee that the flow objects are well formed. The methods introduced here can be useful for debugging or researching. The exception handling adapts the pattern introduced in #364. The new methods subsume `:func: gflow.verify_flow`, `:func: gflow.verify_gflow`, `:func: gflow.verify_pauli_flow`. Additionally, this PR introduces the methods `:func: PauliFlow.get_measurement_label`, `:func: GFlow.get_measurement_label` which return the measurement label of a given node. They follow same criteria employed in the flow-finding algorithms, that is, querying this method on a node with a measurement `Measurement(0, Plane.XY)` will return `Plane.XY` in a `GFlow` or `CausalFlow` and `Axis.X` in a `PauliFlow`. **Additional information on the exception management** ```mermaid --- config: layout: elk elk: mergeEdges: false nodePlacementStrategy: LINEAR_SEGMENTS --- flowchart TD a0(**Exception**) n0(**FlowError**) n1(FlowGenericError) n2(FlowPropositionError) n3(FlowPropositionOrderError) n4(PartialOrderError) n5(PartialOrderLayerError) a0 --> n0 n0 --FGEReason--> n1 n0 --FPEReason--> n2 n0 --FPOEReason--> n3 n0 --POEReason--> n4 n0 --POLEReason--> n5 ``` - Arrows indicate inheritance (from parent to child). - "Reasons" (`FlowPropositionErrorReason`, `PartialOrderLayerErrorReason`, etc.) are `Enum` classes. - Error subclasses: - `FlowPropositionError` - Violations of the flow-definition propositions which concern the correction function only (C0, C1, G1, G3, G4, G5, P4, P5, P6, P7, P8, P9). - Additional parameters: - `node` - `correction_set` - `FlowPropositionOrderError` - Violations of the flow-definition propositions which concern the correction function and the partial order (C2, C3, G1, G2, P1, P2, P3). - Additional parameters: - `node` - `correction_set` - `past_and_present_nodes` - `FlowGenericError` - General errors in the flow correction function, XY planes in causal flow. - Does not require additional parameters. - `PartialOrderError` - General flow and XZ-corrections errors in the partial order. - Does not require additional parameters. - `PartialOrderLayerError` - Flow and XZ-corrections errors concerning a specific layer of the partial order. - Additional parameters: - `layer_index` - `layer` * Fixed typing after removing backend state. * trying to rebase * fixed rebasing and conflicts * fixed changelog and vscode * final fix of changelog * aligning changelog * Ruff fixes * added change to CHANGELOG * Fixed typing of str and Backend functions in and * Final typing fix * Remove Any import. * Pushing again to check CI. * Disabled qasm parser CI tests causing Graphix CI to fail. * Added qasm test back in. * Fixed merge from master. * Fixed merge from master. * fixing added code * fixing CI * fixing imports * fixing typing in tests * fixing typing in tests * fixed test typing * fixed test typing * fixed test typing * fixed test typing * fixing merge problems * fixing import issue --------- Co-authored-by: Emlyn Graham <egraham@PTB-02009984.paris.inria.fr> Co-authored-by: thierry-martinez <thierry.martinez@inria.fr> Co-authored-by: matulni <m.uldemolins@gmail.com>

matulni added 2 commits November 25, 2025 09:28

Add OG comparison

45187eb

Add tests og compare

877be37

matulni mentioned this pull request Nov 25, 2025

Refactor of flow tools - OpenGraph.compose #375

Merged

matulni changed the title ~~Refactor of flow tools - OpenGraph comparison.~~ Refactor of flow tools - OpenGraph.isclose Nov 25, 2025

thierry-martinez reviewed Nov 25, 2025

View reviewed changes

matulni added 4 commits November 26, 2025 17:39

Add comments Thierry's review

b3c3004

Up meas is close and og comparison

ecbbacb

Fix docstring

5ca8698

Merge branch 'master' into rf_og_compare

82cb949

matulni mentioned this pull request Nov 28, 2025

Refactor of flow tools - Verification of flow objects #378

Merged

Merge branch 'master' into rf_og_compare

c4fe9b8

thierry-martinez approved these changes Nov 29, 2025

View reviewed changes

matulni added 2 commits December 1, 2025 10:32

Up opengraph is_equal_structurally

5cd51d6

Remove unnecessary if from Measurement.isclose and up CHANGELOG

9358992

emlynsg approved these changes Dec 2, 2025

View reviewed changes

matulni merged commit cf9171a into TeamGraphix:master Dec 2, 2025
21 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Refactor of flow tools - `OpenGraph.isclose`#374

Refactor of flow tools - `OpenGraph.isclose`#374
matulni merged 9 commits intoTeamGraphix:masterfrom
matulni:rf_og_compare

matulni commented Nov 25, 2025

Uh oh!

codecov bot commented Nov 25, 2025 •

edited

Loading

Uh oh!

Uh oh!

thierry-martinez Nov 25, 2025

Uh oh!

matulni Nov 26, 2025

Uh oh!

thierry-martinez Nov 27, 2025

Uh oh!

matulni Dec 1, 2025

Uh oh!

thierry-martinez Nov 25, 2025

Uh oh!

Uh oh!

Uh oh!

thierry-martinez left a comment

Uh oh!

matulni commented Dec 2, 2025

Uh oh!

emlynsg left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

matulni commented Nov 25, 2025

Uh oh!

codecov bot commented Nov 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Uh oh!

thierry-martinez Nov 25, 2025

Choose a reason for hiding this comment

Uh oh!

matulni Nov 26, 2025

Choose a reason for hiding this comment

Uh oh!

thierry-martinez Nov 27, 2025

Choose a reason for hiding this comment

Uh oh!

matulni Dec 1, 2025

Choose a reason for hiding this comment

Uh oh!

thierry-martinez Nov 25, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

thierry-martinez left a comment

Choose a reason for hiding this comment

Uh oh!

matulni commented Dec 2, 2025

Uh oh!

emlynsg left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

codecov bot commented Nov 25, 2025 •

edited

Loading