Motivation
Some applications like VQE require the optimisation of parameters in a circuit to minimise some cost function (e.g. an energy expectation value). Gradient-based methods are a popular choice; the quantum natural gradient proved particularly efficient. It would be useful to have builtin functionality in pyQuEST that calculates the (natural) gradient so that users don't need to implement their own or use external libraries. @TysonRayJones published the note arXiv:2009.02823 about how to numerically evaluate the gradient more efficiently than a naive implementation. The natural gradient requires additional care to calculate the quantum geometric tensor, as described in arXiv:2011.02991.
Implementation
The gradient functionality is probably best placed in a new submodule named tools.
The interface can be a single function for each, the regular gradient and its "natural" cousin, named gradient(circ, observable) and nat_gradient(circ, observable), respectively. The parameter circ would be a pyQuEST Circuit and observable is a callback function that takes a Register and returns the cost function evaluated on its state. The gradient() and nat_gradient() functions should return a new (not normalised) Register containing the direction of the (natural) gradient in its state.
As a start you may assume each gate in circuit has an independent parameter angle that is to be optimised. You may also explicitly limit the types of gates allowed in the circuit, but make sure to check and raise an appropriate exception if you do.
Initially, a pure Python implementation should be sufficient, but eventually writing it in Cython may show speed improvements.
Notes
-
There is no formal contribution and code style guide, but try to match the conventions established in the existing code. Pull requests may be followed by a linting commit if conventions do not match.
-
The quantum geometric tensor may be (close to) singular in many situations. When inverting it, take care to use some sensible regularisation method. Ideally this would be an optional parameter users can specify, but can also be hard-coded for a first implementation.
Motivation
Some applications like VQE require the optimisation of parameters in a circuit to minimise some cost function (e.g. an energy expectation value). Gradient-based methods are a popular choice; the quantum natural gradient proved particularly efficient. It would be useful to have builtin functionality in pyQuEST that calculates the (natural) gradient so that users don't need to implement their own or use external libraries. @TysonRayJones published the note arXiv:2009.02823 about how to numerically evaluate the gradient more efficiently than a naive implementation. The natural gradient requires additional care to calculate the quantum geometric tensor, as described in arXiv:2011.02991.
Implementation
The gradient functionality is probably best placed in a new submodule named
tools.The interface can be a single function for each, the regular gradient and its "natural" cousin, named
gradient(circ, observable)andnat_gradient(circ, observable), respectively. The parametercircwould be a pyQuESTCircuitandobservableis a callback function that takes aRegisterand returns the cost function evaluated on its state. Thegradient()andnat_gradient()functions should return a new (not normalised)Registercontaining the direction of the (natural) gradient in its state.As a start you may assume each gate in circuit has an independent parameter
anglethat is to be optimised. You may also explicitly limit the types of gates allowed in the circuit, but make sure to check and raise an appropriate exception if you do.Initially, a pure Python implementation should be sufficient, but eventually writing it in Cython may show speed improvements.
Notes
There is no formal contribution and code style guide, but try to match the conventions established in the existing code. Pull requests may be followed by a linting commit if conventions do not match.
The quantum geometric tensor may be (close to) singular in many situations. When inverting it, take care to use some sensible regularisation method. Ideally this would be an optional parameter users can specify, but can also be hard-coded for a first implementation.