Better drawings for control flow
See original GitHub issueWhat should we add?
Currently, if_else
, while_loop
and for_loop
are represented in drawings as black boxes.
Additionally, the tested condition is not explicit in the drawing.
I propose adding a more explicit representation. In the figure below I propose two alternatives, so that we can choose one or discuss an even better option.
Issue Analytics
- State:
- Created a year ago
- Comments:7 (7 by maintainers)
Top Results From Across the Web
How to draw a control Flow Graph ? - YouTube
A CFG captures the flow of control within a program. Such a graph assists testers in the analysis of a program to understand...
Read more >How to draw a Control Flow Graph from this code?
A control flow graph (CFG) in computer science is a representation, using graph notation, ... Here's a cheat sheet which explains it better....
Read more >Software Engineering | Control Flow Graph (CFG)
A Control Flow Graph (CFG) is the graphical representation of control flow or computation during the execution of programs or applications.
Read more >How to draw a Control flow graph & Cyclometric complexity for ...
More like this. Linux Directory Structure (File System Structure) Explained with Examples Computer Coding, Computer Basics. Linux Directory Structure (File ...
Read more >Visualizing Control Flow Graphs - UA Campus Repository
To better support the creation of domain-aware CFG drawings and visual analytics systems that are suited to analysis tasks, we begin by identifying...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@gabrieleagl I thought of something similar to your top drawing, but I think it’s probably simpler and more easily readable if we just put the condition for the IfElseOp in text at the top. And for the loops that would work as well. More demos to follow.
I’m keen to stick close to what Edwin thinks is reasonably implementable here, because we 100% do not have the resources to make Qiskit’s visualisations “perfect”. We’ve generally maintained the position that we would support a more full-featured visualisation package being responsible for the best drawings, and that Qiskit’s internal support is just best-effort.
As a direct response: I think drawing the box around all the affected wires (both qubit and clbit), and not doing something different between qubits and clbits is the best way forwards. There are many edge cases, such as blocks that aren’t on visually contiguous qubits/clbits, that are already considered for opaque instructions (i.e. we draw a box from the top-most qubit to bottom-most clbit and label unused wires), and I think it will be simplest to stick close to that type of approach. It will also mean that if a control-flow block contains one of these opaque instructions, we won’t suddenly end up with the case where an opaque instruction is sticking out of the surrounding control-flow box.
I agree that writing out the condition / loop indices above the box(es) will probably be the neatest (and easier to implement).