a round-trip through graph_to_json and json_to_graph renumbers the vertices

[dlyongemallo]

The graph_to_json and json_to_graph functions work with a JSON format which is "compatible with" Quantomatic. Where is this Quantomatic format documented?

In particular, the vertices are given names based on whether they are boundary or interior vertices on conversion of a graph to JSON ("b1", "v1", and so on), and when these are read back, they are assigned a vertex numbering which no longer corresponds to the original graph. I'm wondering if it would be possible to perserve the original numbering while maintaining compatibility with Quantomatic, for example by just using the labels "bN" and "vN" where N is the original vertex numbering of the input graph. But I don't know if such a change would break compatibility with Quantomatic.

The vertex numbering should probably be perserved before implementing functions to load and save the graphs (issue #187), as there should be a round-trip test that saving and loading a graph results in exactly the original graph.

The vertex renumbering seems to be the cause of issue zxcalc/zxlive#207. After PR zxcalc/zxlive#204, ZXLive is calling graph_to_json and json_to_graph to store the graphs which make up the proof steps, and the vertex renumbering is causing the diffs to be applied incorrectly. (Prior to that PR, the graphs were saved in TikZ format, but that format doesn't support parametrized phases.)

[jvdwetering]

Compatibility with Quantomatic is not really necessary, as Quantomatic has been dead for a couple of years now. I was actually thinking whether it wouldn't make sense to make a new format for saving in json from the ground up that is more reasonable for pyzx and ZXLive.

[akissinger]

Quantomatic file formats are documented here:

https://github.com/Quantomatic/quantomatic/blob/stable/docs/json_formats.txt

Note that a vertex or boundary name can be any string. There is no requirement that they be of the form "bN" and "vN", this is just how it is done in the examples. So, just using the ints as quoted strings should work fine.

When we adopted the Quantomatic format for pyzx, we decided that it was fine to break quantomatic compatibility (hence also using a different file extension). So, I don't think there is a problem making some changes. E.g. adding input/output lists could be useful. I guess currently, it tries to guess the ordering based on the name? We could also ditch the "node-vertex" vs "wire-vertex" distinction, since the only "wire-vertices" we use in pyzx are boundaries, which we already identify their type.

[dlyongemallo]

I guess currently, it tries to guess the ordering based on the name?

The way it's implemented, it puts all the boundary vertices first on save, and assigns the vertex numbers sequentially on load, so unless the original graph had all the boundary vertices up front, the loaded graph's vertices will get numbered differently.

If it's fine to just completely break compatibility, then it would be a good idea to redesign the file format around what is necessary and convenient for PyZX and ZXLive.

[jvdwetering]

Ordering of inputs/outputs was based on position, but that's changed now and it actually stores which number of input or output it was separately. As this changed broke backwards compatibility anyway, maybe now is a good time to have a different json format altogether.