Quantum natural gradient

[MatteoRobbiati]

After closing the dedicated PR in Qibo, this issue exists as a reminder natural gradient is a feature we want to support in the future.

[renatomello]

There is a plan to have a function that calculates the quantum_fisher_information_matrix inside the quantum_info module after qiboteam/qibo#1450 is merged, and ideally, before the v1 of the paper is out (next 6 weeks).

Here is an old issue on qibo about it qiboteam/qibo#657.

The QFIM is essentially the metric tensor needed for the natural gradient. What would be the best way to integrate these two ideas? Because that would introduce a circular dependency between qibo and qiboml.

[alecandido]

In general, an abstract interface for obtaining gradients from a backend (if provided) should be present in Qibo, since the Backend itself is still part of Qibo (possibly to be moved to qibo-core, at some point).

But no implementation for the gradient extraction should be supported by Qibo backends' themselves, while they should be in those present here.

A higher level interface for accessing gradients may be provided in here, but it should not prevent to access the same information from the bare gradient, and reconstructing the same function somewhere else.

If instead you want to use the PSR or something else to compute a gradient while that is not natively provided, then functions using this feature should be split out of the main qibo package, and depending on both qibo and qiboml, since this is definitely an "advanced" QML support, that has to be in qiboml.
The only other alternative is to give up completely in qiboml and keep everything as part of a unique qibo package, which is the opposite direction wrt the one we are taking.

[renatomello]

But no implementation for the gradient extraction should be supported by Qibo backends' themselves, while they should be in those present here.

This strict rule will create issues, e.g. qiboteam/qibo#1485. Now what happens when gradient descent is for tomography (or any other quantum info application in the present or future) and not for some variational model?

I do not have a solution to this problem, but contradictions will inevitably happen (e.g. the QFIM function I mentioned and this new PR opened).

As I mentioned to @stavros11 in person, my first idea to implement the QFIM function was to implement an AbstractBackend.calculate_gradients that raises a NotImplementedError for all backends but the ones that support automatic differentiation.

[alecandido]

As I mentioned to @stavros11 in person, my first idea to implement the QFIM function was to implement an AbstractBackend.calculate_gradients that raises a NotImplementedError for all backends but the ones that support automatic differentiation.

That's exactly what I said above...

an abstract interface for obtaining gradients from a backend (if provided) should be present in Qibo

This would be AbstractBackend.calculate_gradients (I may prefer a different name, but it's not relevant).

But no implementation for the gradient extraction should be supported by Qibo backends' themselves, while they should be in those present here.

This is the NotImplementedError statement.

The only additional part is that will only get native gradients, while others may be available. So, if you use the QibolabBackend (or even just the NumpyBackend), you may obtain the gradient from the PSR. Still, if you will attempt to compute the QFIM with those backends, you'll just receive an error.
This limitation will stay, since the additional gradients will be provided by qiboml, and the only dynamic dependency we will manage it will be the backends (everything else, has to depend statically). This means that code in Qibo will be able to use the qiboml backends (if loaded by the user), and nothing else of qiboml. Otherwise, you have to move this code outside the main qibo package.

[renatomello]

@MatteoRobbiati @BrunoLiegiBastonLiegi To implement the QNG it makes more sense to create another submodule called optimizers. Is that ok?

[BrunoLiegiBastonLiegi]

Sure, sounds good to me. I would even remove the current operations/ module and have the 4 modules:

qiboml/
    models/ 
    interfaces/
    differentiation/
    optimizers/

[MatteoRobbiati]

@MatteoRobbiati @BrunoLiegiBastonLiegi To implement the QNG it makes more sense to create another submodule called optimizers. Is that ok?

Sounds good to me!
Maybe, to avoid having a lot of submodules, we could change the current configuration in something like:

qiboml
    - backends
    - interfaces
    - models
    - optimization
        - optimizers
        - differentiation

Anyway, for me no problem.

[alecandido]

There is no optimal way for nesting more or less: in principle, you'd like to balance depth and breadth, but keeping the subdivision meaningful.

In any case, just consider that nesting too much often makes navigating considerably more inconvenient. So, do not fear too much a growing number of elements in a single folder.

But I'm definitely not pushing too much for any of the two alternatives. At this level, both are good enough.