Circuit layout

[alecandido]

The current Circuit is mainly composed of a _Queue, that is essentially a list of gates.

This is not a bad, because the essential feature of gates is being sorted, so happening after some others.

If there were only single qubit gates, this would have not been the best choice, since the sorting would have been local. In that case, one list per qubit should have been the optimal representation.
Since this is not the case, that alone is not an option.

Then, there are a few options:

1. keep the current layout, i.e. a single list and the qubits information within the gates
2. same, but with gate wrappers
3. use multiple lists, and copy & link the multi-qubit gates on each list involved (even with a main one and further satellites)
4. use a graph

The last option would get closer to the tensor network idea, and make all the information about the connections transparent, without any need to reconstruct from the gates. In principle, we could even just place identifiers in the graph itself, and store the actual gates in a separate list (that's again similar to the current layout, but stripping any sequence semantics from the list, and the qubits specification from the gates).

I'm tempted to attempt the graph way, it should make it simpler also to represent controlled gates. Do you see any drawback?

[scarrazza]

The graph approach is the most interesting. In fact, we could take this opportunity to:

• optimize and parallelize gate operations, e.g, we could stack variational versions of a given circuit together and design operators for parallel execution,
• transpile the graph more efficiently in a compiled language.

Another relevant point is the qubit representation, I think we should reconsider a more general approach to the problem by including a representation of multi level quantum systems (qubit, qutrid and beyond).

[alecandido]

As already declared in #6, I'd like to avoid explicit references to qubits/qudits. They are not strictly required to create some gates, nor a circuit (we just need to refer to some sort of local subsystems - for the time being, I'm calling them elements).

The current strategy is summarized in the related docs:

qibo-core/src/circuit.rs

Lines 3 to 12 in efb6992

	/// A discrete gate-based representation of a quantum computation.
	///
	/// The circuit is represented as an unstrtuctured set of gates, with their connectivity separately
	/// recorded by an adjacency list.
	/// Moreover, a circuit is not a random graph, but rather a set of wires, with possible links
	/// across them. This is represented by recording the circuit ends, where it is possible to append
	/// further gates, including measurements. They identify the quantum elements (local subsystem)
	/// where the gates are acting on.
	#[derive(Debug)]
	pub struct Circuit {

However, while this could work for just single qubits gates (you only need to know where to append your gates, or to measure, that is one special case), it doesn't work for asymmetric multi-qubit gates.
Indeed, the current assumption is that a wire enters, and a wire exits, or even some of them. But while is not needed to identify exactly which are the wires for simulation of symmetric gates (think about the TN graphs), this is required when applying an asymmetric gate: a CNOT is a node with 4 legs, two entering and two going out. But they are not all equal.

My current idea is to start thinking gates as subgraphs, rather than atomic nodes. The internal connectivity is not relevant, as long as there is some kind of convention, but the relevant part is that each leg will be connected to a different node. I.e.:

• a single qubit gate will be a set of two nodes: incoming and outgoing
• n-qubit gates will be sets of 2n nodes, potentially all different

The simplest way I can imagine is to use pairs of integers to identify nodes, where the first element will identify the gate, and the second the index internal to the gate (and, by internal convention, 2n will be the n-th incoming and 2n + 1 the n-th outgoing wire).