Quantum automatic differentiation

[comp-phys-marc]

Context: Implementing the quantum automatic differentiation algorithm detailed in this paper from the Quantum Systems Lab at Yale University.

Description of the Change:

1. We check if we have a work wire -> direct or standard differentiation.

2. check if we are doing forward or reversed (switch the generator with the measured op) based how many combinations there are. Depends on the combinations of expectations and terms in the Hamiltonian, for example. i.e. if the terms in the Hamiltonian are on different wires we can measure them at the same time, but still need different circuits for the controls, can refer to the hamiltonian’s "grouping indices" list: its length gives the number of shots need for the expectations. See Table III in https://arxiv.org/pdf/2408.05406 for exact formulas.

Benefits: Allows the optimal differentation method to be selected automatially based on the number of shots required and the availability of auxilliary wires.

Possible Drawbacks: Still a Work In Progress (WIP) needing feeback!

Related ShortCut Stories: [sc-103833]

[comp-phys-marc]

One small issue @albi3ro ... grouping_indices is only going to work if we have a linear combination of Pauli terms. From some of the language in the paper, it seems that this is what we expect to have. However, in many of the tests we have Rx, Ry, IsingXX, CRot, etc. which are not compatible with the current approach.

Certainly the observables should be given in terms of Paulis...

The examples for the Hamiltonians provided and the method discussed to calculate the groupings are also in terms of Paulis, in the table which is really the most relevant piece of the paper to this PR.

[comp-phys-marc]

One small issue @albi3ro ... grouping_indices is only going to work if we have a linear combination of Pauli terms. From some of the language in the paper, it seems that this is what we expect to have. However, in many of the tests we have Rx, Ry, IsingXX, CRot, etc. which are not compatible with the current approach.

Certainly the observables should be given in terms of Paulis...

The examples for the Hamiltonians provided and the method discussed to calculate the groupings are also in terms of Paulis, in the table which is really the most relevant piece of the paper to this PR.

I think I just needed to make more use of _get_pauli_generators which is quite general. This seems to work.

    trainable_op, _, _ = tape.get_operation(trainable_param_idx)
    _, generators = _get_pauli_generators(trainable_op)
    _, observables = _get_pauli_terms(
        tape.measurements[0].obs
    )  # assumes there's only one observable in the tape

    def _count_shots(paulis):
        op = Sum(*paulis)
        op.compute_grouping()
        return len(op.grouping_indices)

    expectations_shots = _count_shots(generators)
    observables_shots = _count_shots(observables)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.42%. Comparing base (7d228c3) to head (ad4f8a1).
⚠️ Report is 2 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #8640      +/-   ##
==========================================
- Coverage   99.42%   99.42%   -0.01%     
==========================================
  Files         587      587              
  Lines       61967    61989      +22     
==========================================
+ Hits        61612    61633      +21     
- Misses        355      356       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[comp-phys-marc]

@isaacdevlugt I wanted to ask you about this module in terms of documentation, etc. At the moment I have written my function in keeping with the rest of the module i.e. there are dev comments but, as with the other private functions in the module, there is no function docstring. Is this kosher or do we want to update the entire module to have more robust documentation?