HT gradient - additional modes

[dtlics]

Context: Hadamard gradients method variants

Description of the Change: added support for different modes in hadamard gradient and implemented direct HT, reversed HT and reversed_direct HT

Benefits: more variants of HT + measurement grouping generates better efficiency for gradient estimation

Possible Drawbacks: for reversed methods, that is reversed HT and reversed_direct HT, the current version does not support circuits with multiple measurements. One will need to modify the processing_fn in how it aggregates the results so support this. For non-reversed methods, we aggregate for each measurement and the code work because the shape is N_G*M where N_G is the number of terms in the generator and M is the number of measurements. However, in reversed method, the shape is [N_1, ..., N_M], where for the i-th measurement, there are N_i gradient tapes. Different measurement has different number of tapes, and all the tape has only one measurement, so one does not need to aggregate across dimensions, just group neighboring ones would do.

Related GitHub Issues:

[albi3ro]

So for the failing test, we keep a hardcoded list of potential gradient keyword arguments here:

pennylane/pennylane/gradients/gradient_transform.py

Line 24 in 7bdf71b

SUPPORTED_GRADIENT_KWARGS = {

This was done as a patch to add validation to the QNode(qfunc, dev, ... , **gradient_kwargs) way of passing gradient keyword arguments and catching mistakes. Gladly, we will be getting rid of that in April, but for now, we will need to add "mode" to that hardcoded set.

[albi3ro]

When we are using the generator as a meausrement, do we still need to represent the observable as a linear combination of unitaries (paulis)?

Or could we technically just do:

mp = qml.expval(trainable_op.generator() @ qml.Y(aux_wire))

This might be a bit more general, and leaves interpreting the new observable up to the device.

[dtlics]

Awesome, I changed the how the measurements are constructed, everything works well so far.

I also added the keyword "mode" into that hardcoded set.

[dtlics]

BTW, with this implementation, if a user wants to minimize the number of distinct circuits, would the device be able to apply measurement grouping with respect to this expval?

[albi3ro]

Yep. Measuremet grouping is on by default now with split_non_commuting.

[codecov]

Codecov Report

Attention: Patch coverage is 23.61111% with 55 lines in your changes missing coverage. Please review.

Project coverage is 99.48%. Comparing base (897c041) to head (036e3fc).
Report is 14 commits behind head on master.

Files with missing lines	Patch %	Lines
pennylane/gradients/hadamard_gradient.py	23.61%	55 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #7046      +/-   ##
==========================================
- Coverage   99.60%   99.48%   -0.12%     
==========================================
  Files         490      496       +6     
  Lines       47256    47393     +137     
==========================================
+ Hits        47070    47151      +81     
- Misses        186      242      +56     

☔ 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.

[albi3ro]

For reversed and direct reversed, can we add a check making sure there is only one meausrement, and raising a ValueError if not?

We could also add this validation up near the other validation checks, like the assert_no_state.

The benefit of having it here is that we've already dispatched by mode, but the benefit of having it by the other assertions is that we would only have to run it once.

[albi3ro]

At this point, the different modes are accessible via:

qml.QNode(f, dev, diff_method="hadamard", gradient_kwargs={"mode": "reversed"})

To automatically choose the mode from a string diff_method, we will need to update this workflow function:

pennylane/pennylane/workflow/resolution.py

Line 163 in db404c0

def _resolve_diff_method(

to be able to interpret the various hadamard options. We can do so in this PR, but I'd prefer to do that in a follow on.

[albi3ro]

Given direct and reversed direct don't need an aux wire, bypass the the extraction of the aux_wire if the mode is direct or revesed direct:

    aux_wire = _get_aux_wire(aux_wire, tape, device_wires)

Potentially just leaving it None if when we don't need it. This will allow us to direct and reversed direct when we don't have any bonus wires.