Currently, we use a string to track the measurement outcomes from code circuits. By adding a class for this instead of using a string, we can eliminate a whole range of cryptic errors when, for example, passing the results to a incorrectly configured decoder.
For the data on the edges and the nodes of the syndrome graph, we currently use dictionaries. Adding classes for nodes and edges solves the same issues as above.
Each decoder could create a class that inherits from the node base class and can store the required information in there. The same thing could be done for edges.
It would also make it easier to differentiate between bulk and boundary nodes, as they can be separate classes.
DecodingGraph would take two additional arguments in in its constructor, which are the node and the edge class. By default these would be the base classes.
Not only would this change make the code safer, it would make it easier to easily track nodes, which could introduce some speed-ups.
tommasopeduzzi
commented
1 year ago
What is the expected enhancement?
Currently, we use a string to track the measurement outcomes from code circuits. By adding a class for this instead of using a string, we can eliminate a whole range of cryptic errors when, for example, passing the results to a incorrectly configured decoder.
For the data on the edges and the nodes of the syndrome graph, we currently use dictionaries. Adding classes for nodes and edges solves the same issues as above. Each decoder could create a class that inherits from the node base class and can store the required information in there. The same thing could be done for edges. It would also make it easier to differentiate between bulk and boundary nodes, as they can be separate classes. DecodingGraph would take two additional arguments in in its constructor, which are the node and the edge class. By default these would be the base classes. Not only would this change make the code safer, it would make it easier to easily track nodes, which could introduce some speed-ups.