SciPost Submission Page
QGOpt: Riemannian optimization for quantum technologies
by I. A. Luchnikov, A. Ryzhov, S. N. Filippov, H. Ouerdane
|As Contributors:||Ilia Luchnikov · Henni Ouerdane · Alexander Ryzhov|
|Arxiv Link:||https://arxiv.org/abs/2011.01894v2 (pdf)|
|Date submitted:||2021-02-05 13:30|
|Submitted by:||Ouerdane, Henni|
|Submitted to:||SciPost Physics Codebases|
Many theoretical problems in quantum technology can be formulated and addressed as constrained optimization problems. The most common quantum mechanical constraints such as, e.g., orthogonality of isometric and unitary matrices, CPTP property of quantum channels, and conditions on density matrices, can be seen as quotient or embedded Riemannian manifolds. This allows to use Riemannian optimization techniques for solving quantum-mechanical constrained optimization problems. In the present work, we introduce QGOpt, the library for constrained optimization in quantum technology. QGOpt relies on the underlying Riemannian structure of quantum-mechanical constraints and permits application of standard gradient based optimization methods while preserving quantum mechanical constraints. Moreover, QGOpt is written on top of TensorFlow, which enables automatic differentiation to calculate necessary gradients for optimization. We show two application examples: quantum gate decomposition and quantum tomography.
Author comments upon resubmission
Thank you for giving us the opportunity to submit a revised manuscript for further consideration.
We have read the three reports carefully and with interest. We thank the Referees for their useful
and encouraging reviews that provided actual scope for improvement of our manuscript and QGOpt,
and provided also an engaging discussion. In our reply to the reports (see the SciPost Reply to Report Page)
we answer each of the points raised by the Referees, and we give a summary of the changes made to our manuscript.
Henni Ouerdane, on behalf of all coauthors.
List of changes
1. Specify a package version to which the manuscript pertains. I noticed there has been unreleased development
on the master branch. If you want to follow "semantic versioning", you may want to declare the
package API "stable", release a 1.0, and write the manuscript specifically for that.
The package version is 1.0.0, and it is specified in the subsection 4.1 Manifolds API, page 8 of the revised manuscript.
2. The package needs to have *automatic* testing. The example notebooks are very nice, but not automatic
(ensuring that future development will not break the package, or make it easy for new contributors to
add code). I noticed that the repository includes some test code. I would recommend to set up continuous
integration (Github Actions) to run the tests automatically. Also, the documentation must include some
guidelines for contributors, most importantly how to run the tests manually.
All manifolds in the QGOpt 1.0.0 library are automatically tested. We also added automatic tests for the optimizers
for the example of the optimization problem on the Stiefel manifold.
3. Consider adding tutorials for *all* the supported manifolds. This is somewhat optional, and could be
done after publication. On the other hand, it might uncover bugs/problems that you’d want to fix before
publication or a 1.0 release. Rename "Quick Start" to "Quick Start: Quantum Gate decomposition".
We plan to include in the near future tutorials for the manifold of Hermitian matrices and the manifold of
complex positive definite matrices. At present, we offer a "Quick start tutorial" on the complex Stiefel manifold.
Four additional tutorials are provided: complex Stiefel manifold, density matrices of fixed rank manifold, Choi matrices
of fixed rank manifold, and POVMs manifold.
4. Include a discussion of the scaling of numerical cost, and briefly compare to second-order gradient optimization.
This discussion is the object of the new Appendix B; however, at present we could not find a fast way to compare the
first-order Riemannian optimization methods of QGOpt with second-order Riemannian optimization methods.
Indeed, second-order methods are not yet developed for the manifolds considered by QGOpt, and this would require
extensive work to develop such methods.
5. Correct the typos, and implement the change of mathematical notation pointed out in the reports.
List of major additional changes:
1. The Introduction is revised.
2. Section 2 has been extended.
3. The new Section 6 is added.
4. Appendix A and Appendix B are added.
Submission & Refereeing History
You are currently on this page
Reports on this Submission
Report 3 by Michael Goerz on 2021-2-21 Invited Report
In their latest revision, the authors have sufficiently addressed all of my concerns. In terms of content and organization, I have no further comments and fully support publication of the manuscript in its current form.
A fair number of stylistic/grammatical/punctuation problems still exist and should be edited. I am attaching an annotated pdf with some suggestions.
Some points that stood out:
* For Eq. (12), I strongly recommend using the same notation that the first paragraph of Boumal's book's introduction (Ref ) defines.
* You usually don't have to write something like "in the following way" before an equation, e.g., Eq. (10), or a code example.
* Unlike with equations, I don't think you can put punctuation in code lines. Specifically with commas (second code block on p. 14), it changes the semantics: opt is not a tuple! The periods would be syntax errors, so at least they don't introduce a bug. I've struggled with this problem myself, but I can't think of any good solution apart from just omitting the punctuation, or using floats for longer code blocks.
* The typesetting of the newly added tables can be much improved: Generally, you shouldn't use vertical lines or horizontal lines between each row. See https://texblog.org/2017/02/06/proper-tables-with-latex/ or http://tug.ctan.org/macros/latex/contrib/booktabs/booktabs.pdf for guidelines on typesetting tables. I might make an exception for Table 1 due to the amount of text. However, Table 1 should probably be rotated and made wider to fill the entire page in landscape. Tables 3-4 should use the full page width and definitely omit all vertical and most horizontal lines. If a table does not need the full page width, it should be centered on the page.
Anonymous Report 2 on 2021-2-19 Invited Report
The main remarks of my previous report have been taken into account.
I am not sure why the authors did not feel like accepting my advise not to write \mapsto to denote a function (see, e.g., line 7 of p.4 in the revised version). This is a plain misuse of mathematical notation, but I agree that your readers will understand anyhow.
Anonymous Report 1 on 2021-2-7 Invited Report
since all the required changes have been made, I support the publication of this paper.