Support for weighted gates in graph decomposition algorithm

[comp-phys-marc]

---

Context: In short, a decomposition system based on a graph traversal using Dijkstra's algorithm is applied to find the most optimal gate decompositions for non-native gates. The nodes in the graph represent either decompositions, operations in the target gateset, or higher order operations. The edges show either membership of a native op in a decomposition, or equivalence of a decomposition to a higher order operation. The cost of an edge between a native operation and a decomposition is the number of additional gates found in the decomposition. The cost of an edge between a decomposition and an equivalent higher order op is zero. For more context, see [sc-84664].

Description of the Change: Work in progress on implementing support for relatively weighted gates within a target gateset. The weights are provided by the user, and influence what gate decompositions are chosen by the graph decomposition algorithm. The implementation is such that the weights of the gates are represented by weights on the edges leading to and from native gates.

Benefits: Allows a user to more closely model the behaviour of their backends, and capture the relative cost of executing certain gates such as non-Clifford gates which are native, but more expensive.

Possible Drawbacks: The representation of weights in this way is possibly not intuitive.

Related GitHub Issues:

[isaacdevlugt]

@comp-phys-marc nice work 🎉! Just made some suggestions to redirect documentation more towards what the user will want to use.

[isaacdevlugt]

Suggested change

	raise ValueError("Gate weights provided in a `dict` type `gate_set` parameter to `decompose`"
	"must not be negative, as negative gate weights are not supported.")
	raise ValueError("Negative gate weights provided to gate_set in decompose"
	"are not supported.")

[comp-phys-marc]

Done!

[isaacdevlugt]

I made a suggestion to the error message above, so just a note to change the tests too!

[comp-phys-marc]

Roger!

[isaacdevlugt]

🍾 🥳

[isaacdevlugt]

This is a nice example for power users and developers, but the majority users won't interact with the DecompositionGraph object 🙂. With code examples in the changelog, they should always be showing something that the user will want to do (or what we want to direct the user to do).

Here, we should have an example like this:

gate_set = {"RX": 1.0, "RY": 3.0, "RZ": 10.0, "GlobalPhase": 1.0, "CNOT": 20.0, "CZ": 1.0}

@partial(decompose, gate_set=gate_set)
@qnode(...)
def circuit(...):
    ...

print(qml.draw(circuit, level="device"))

Really simple toy example that reflects a real-world scenario 😄

[comp-phys-marc]

Great feedback! I will create some examples in this style. Thanks!

[comp-phys-marc]

I've addressed this in my most recent commit, let me know if you would like any further changes like more or different examples.

[isaacdevlugt]

Yay! Nice! 🚀

[astralcai]

Great work! Congratulations on your first contribution! 🚀 Let's wait for a second technical review from @PietropaoloFrisoni but I'm happy to approve.

[PietropaoloFrisoni]

Congratulations @comp-phys-marc , this is really an impressive work 🎉

I only have a couple of minor comments/questions, but pretty much ready to approve : )

[PietropaoloFrisoni]

If I run this example, I get a different output (the Hadamard gate is not decomposed):

import pennylane as qml
from functools import partial
qml.decomposition.enable_graph()

@partial(
    qml.transforms.decompose, gate_set={qml.Toffoli: 1.23, qml.RX: 4.56, qml.RZ: 0.01, qml.H: 420}
)
@qml.qnode(qml.device("default.qubit"))
def circuit():
    qml.H(wires=[0])
    qml.Toffoli(wires=[0, 1, 2])
    return qml.expval(qml.Z(0))

>>> print(qml.draw(circuit)())
0: ──H─╭●─┤  <Z>
1: ────├●─┤     
2: ────╰X─┤

Am I missing something? Do I need to test this using a different branch?

[comp-phys-marc]

Aha I found what is happening here. The way the stopping condition is implemented, it just checks if the gate is in the target gateset, and if it is then it stops. It never gets to _construct_and_solve_decomp_graph in this case, so no graph based decomposition occurs.

[comp-phys-marc]

A better example might be the following. It shows how we avoid decompositions involving H when the cost of H is high just as well, and it works properly. Let's please discuss though whether the functionality around decomposing (or the lack of decomposing) gates in the target gateset is as desired.

@partial(
    qml.transforms.decompose, gate_set={qml.Toffoli: 1.23, qml.RX: 4.56, qml.CZ: 0.01, qml.H: 420, qml.CRZ: 100}
)
@qml.qnode(qml.device("default.qubit"))
def circuit():
    qml.CRX(0.1, wires=[0, 1])
    qml.Toffoli(wires=[0, 1, 2])
    return qml.expval(qml.Z(0))

>>> print(qml.draw(circuit)())

0: ───────────╭●────────────╭●─╭●─┤  <Z>
1: ──RX(0.05)─╰Z──RX(-0.05)─╰Z─├●─┤     
2: ────────────────────────────╰X─┤     

@partial(
    qml.transforms.decompose, gate_set={qml.Toffoli: 1.23, qml.RX: 4.56, qml.CZ: 0.01, qml.H: 0.1, qml.CRZ: 0.1}
)
@qml.qnode(qml.device("default.qubit"))
def circuit():
    qml.CRX(0.1, wires=[0, 1])
    qml.Toffoli(wires=[0, 1, 2])
    return qml.expval(qml.Z(0))

>>> print(qml.draw(circuit)())

0: ────╭●───────────╭●─┤  <Z>
1: ──H─╰RZ(0.10)──H─├●─┤     
2: ─────────────────╰X─┤