add ECR gate and approximation_degree option

[ajavadia]

Adds a new 2-qubit gate, the echo cross-resonance (ECR), which is two CR(π/4) pulses with an X gate between them for the echo. This gate is locally equivalent to a CNOT (can convert to a CNOT with local pre- or post-rotation). It is the native gate on current IBM hardware and compiling to it allows the pre-/post-rotations to be merged into the rest of the circuit.

Additionally a new option is added to the transpiler for approximate synthesis of unitaries. The synthesis fidelity can be given to the transpiler. This capability was already there in the synthesizer, it is just now exposed to the transpiler.

[kdk]

Looks good, two small test comments, but otherwise, good to go.

[levbishop]

"Synthesis fidelity" is not a good description of the parameter. "Basis fidelity" is better. The actual meaning of the parameter is that it assumes each use of the 2-qubit basis gate has the given gate fidelity, and trades that off with the approximation fidelity. For example if the target gate is the small fractional SWAP exp(0.0647 i (xx+yy+zz)) then with basis_fidelity=0.9966 the decomposer will prefer the 0.99 gate fidelity 0-CNOT product decomposition in preference to the perfect 3-CNOT decomposition, whereas in this case I would say the "synthesis fidelity" is 0.9900

[ajavadia]

"Synthesis fidelity" is not a good description of the parameter. "Basis fidelity" is better. The actual meaning of the parameter is that it assumes each use of the 2-qubit basis gate has the given gate fidelity, and trades that off with the approximation fidelity. For example if the target gate is the small fractional SWAP exp(0.0647 i (xx+yy+zz)) then with basis_fidelity=0.9966 the decomposer will prefer the 0.99 gate fidelity 0-CNOT product decomposition in preference to the perfect 3-CNOT decomposition, whereas in this case I would say the "synthesis fidelity" is 0.9900

Yes but I wanted to somehow avoid making this too specific to this pass. I'm trying to add a knob to the high-level "transpile" command that allows users to control approximation degree. You can imagine this knob can be useful in things like compiling to a discrete gate set, or using approximate QFT, or whatnot. I know this particular pass makes its approximation decision based on finding a sweet spot in the tradeoff between applying more gates and fidelity of synthesis. So I'd be open to suggestions for a general name. Would "approximation_degree" be good?

[levbishop]

I know this particular pass makes its approximation decision based on finding a sweet spot in the tradeoff between applying more gates and fidelity of synthesis. So I'd be open to suggestions for a general name. Would "approximation_degree" be good?

Wouldn't finding a sweet spot between gates fidelity and synthesis fidelity be fairly generic also to things like Solovay-Kitaev or whatever? I would argue that some interpretation basis_fidelity could/should be used in many/most circumstances.

[ajavadia]

Ok I think I understand what you mean. You're saying the minimum basis fidelity that would make a difference to your approximation is basis_gate of 0.4 fidelity.

That's even though the approximation itself can go lower than 0.4 in the Weyl chamber:

average_gate_fidelity(SwapGate(), CXGate()) = 0.25

I'm happy to do whatever you prefer here. I do want to make a follow up PR where I make the basis_fidelity reference those from backend.properties() if available, so that each gate can be approximated according to its own basis fidelity. It should only fall back on this generic approximation_degree in the absence of cal information.

[levbishop]

After optimizing over single-qubit pre/post rotation max_{pre/post} F_avg(SWAP, CX) == 0.4

[levbishop]

perhaps the right thing is to require that approximation-aware synthesis methods expose an approximation_degree kwarg as well as whatever their domain-specific kwarg such as basis_fidelity, or rtol, or search_depth or whatever. Each synthesis method can check that it only receives at most one such kwarg and can do its own domain-specific mapping from the 0<=approximation_degree<=1 range to their native parameter?

[ajavadia]

Yes I think something like that makes sense, a pass-specific parameter and a generic parameter that can be mapped to that for each pass. I can do this for the 2-qubit synthesizer in the follow-up PR.