Hyper-efficient unitary diamond distance

[owenagnel]

Summary

Adds a new method unitary_diamond_distance to qiskit.quantum_info.operators.measures. This method implements a trick discussed in [1] for calculating the diamond norm (completely bounded trace norm) of a difference of unitary channels (also known as the diamond distance). The implementation is composed of three steps:

• Find the eigenvalues of $U^† V$ where channel1 = $U \cdot U^†$ and channel2 = $V \cdot V^†$
• Find the distance $d$ between origin and convex hull of eigenvalues
• Plug this distance into $2\sqrt{1-d^2}$

Refer to issue #12341 for more details.

Citations

[1] D. Aharonov, A. Kitaev, and N. Nisan, “Quantum circuits with mixed states,” in Proceedings of the thirtieth annual ACM symposium on Theory of computing, pp. 20–30, 1998.

fixes #12341

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[qiskit-bot]

Thank you for opening a new pull request.

Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient.

While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone.

One or more of the the following people are requested to review this:

• @Qiskit/terra-core

[kevinsung]

Is this ready for review? If not, please convert it to a draft PR.

[owenagnel]

Hi Kevin, I'm pretty happy with it as is. Went through the CONTRIBUTING.md document and hopefully checked off everything. Would be great if someone with more experience contributing could go through it quickly (only a couple changes). All tests and lifting are passing on my machine using tox.

[coveralls]

Pull Request Test Coverage Report for Build 9016815724

Details

• 30 of 34 (88.24%) changed or added relevant lines in 3 files are covered.
• 7 unchanged lines in 2 files lost coverage.
• Overall coverage increased (+0.02%) to 89.648%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
qiskit/quantum_info/operators/measures.py	28	32	87.5%

Files with Coverage Reduction	New Missed Lines	%
qiskit/transpiler/passes/synthesis/unitary_synthesis.py	3	88.02%
crates/qasm2/src/lex.rs	4	92.37%

Totals
Change from base Build 9004289325:	0.02%
Covered Lines:	62237
Relevant Lines:	69424

---

💛 - Coveralls

[chriseclectic]

I look forward to seeing the proof of this result.

In general I think it makes more sense to make this function a more general diamond_distance function with a specialized efficient case for two unitary inputs (like we have specialized cases for fidelity and other functions with unitary inputs), and the general case can be a call to the existing diamond_norm function.

[chriseclectic]

If these tests aren't too slow it it might be nice to add a loop here to run over a bunch of random unitaries rather than just 1.

[owenagnel]

On my machine it takes around 5.22s to evaluate the diamond norm for 3 qubit channels. Maybe we can run over a bunch of unitaries when num_qubits < 3 and only run one test otherwise?

[chriseclectic]

It would also be good to add some random unit tests for comparing random cliffords, and random paulis for the new function to the diamond norm.

[owenagnel]

I'm curious what this adds at the moment. Perhaps if optimisations are added in the future for Pauli channels or Cliffords this would make sense... But to be honest, I can't think of a simple optimisation for Clifford circuits (please let me know if you have something in mind).

[owenagnel]

I look forward to seeing the proof of this result.

In general I think it makes more sense to make this function a more general diamond_distance function with a specialized efficient case for two unitary inputs (like we have specialized cases for fidelity and other functions with unitary inputs), and the general case can be a call to the existing diamond_norm function.

Hi Chris! Thanks for the comments, and I completely agree, it makes more sense to generalise the function to all CPTP channels. Regarding the proof, I'm quite happy to send it to you, however, it is part of a dissertation submitted for examination and shouldn't be circulated for the time being. Shall I send it to your IBM email?

I'll make the changes you outlined ASAP.