Extending the gate set

[CQargi]

We are writing some standard gate decompositions of multi-qubit gates (e.g. CCX/Y/Z) using the gates available in guppy into guppy-algorithms to make them reusable by others.
Should we move them into guppy? Or, should we keep guppy gate set small and write other gates into guppy-algorithms?

[mark-koch]

There is a question here whether the std library should just provide opaque gate definitions where the compiler decides the lowering (e.g. the current guppylang.std.quantum.toffoli), or if the std library actually provides an implementation with a concrete decomposition strategy (e.g. a particular Clifford+T decomposition)?

Probably also relevant for the qec croud. Thougts? @ss2165 @PabloAndresCQ @hsemenenko @cqc-alec

Broader question is what should our general criterion be for upstreaming things into the std library?

[cqc-alec]

IMO the std library shouldn't specify a particular decomposition, because different decompositions may be desirable in different cases (e.g. Clifford+T versus native gates) -- this should be decided by the compiler.

[perlinm]

(UPDATE: looks like much of my comment below is invalidated by the availability of std.qsystem. My bad. In light of this, I think that having a default decomposition is okay as long as the documentation for the gate is clear and explicit about the choice of decomposition -- and the fact that it is not unique.)

Also chiming in to say that aside from very obvious cases (like CX), I think that gates should not come equipped with a decomposition strategy. If anything, I do not think that Toffoli or CH should even be available in the same namespace as CZ.

If you want to be nicer to users by providing more gates, it may be reasonable to make an explicit (namespace) distinction between "base" gates (again, within reason, e.g. include CX) and "composite" gates such as Toffoli or CH. It would be fine for explicitly composite gates to have a canonical decomposition.

[perlinm]

While we're at it, can we add gates like quantum.rzz and quantum.rxx? My understanding (maybe I'm wrong?) is that the actual native gate on Quantinuum hardware is RZZ, so I was quite surprised that I had to construct a custom RZZ out of the available quantum.crz.

[cqc-alec]

This gate (along with other Quantinuum native gates) is available as std.qsystem.zz_phase: https://docs.quantinuum.com/guppy/api/generated/guppylang.std.qsystem.zz_phase.html#guppylang.std.qsystem.zz_phase .

[perlinm]

I see, thanks!