Adds utility functions for the general parameter-shift rule

[josh146]

Context: In #1788, a utility function to generate parameter-shift rules, given an operators spectrum, was added. As per the recent gradient ADR, the decision was made to use this pipeline as the default method for the parameter-shift rule in PennyLane, and deprecate the Operator.grad_recipe attribute.

This PR introduces several changes, and new utility function, in preparation for this move.

Description of the Change:

• The function get_shift_rule was renamed to _get_shift_rule, and wrapped by a new user-facing wrapper function generate_shift_rule, to emphasize that the shift rule is computed, rather than retrieved.

• As the grad_recipe is due to be removed from the parameter-shift logic (kept only as a fallback option), generate_shift_rule has been modified to simply return an array of shifts and coefficients.

• generate_shift_rule automatically removes negative frequencies, so that it can be used with qml.fourier.spectrum (which returns both positive and negative frequencies).

• _process_gradient_recipe has been added, which processes the shifts and coefficients to remove redundant shifts. In particular:

  • All small coefficients and shifts (up to a certain tolerance) are set to 0

  • Terms where the coefficients are 0 are removed

  • The terms are sorted as per abs(shift), to ensure that any unshifted terms are first.

  • Terms with the same shift value are combined, with corresponding coefficients summed.

• A utility function, eigvals_to_frequencies is provided, allowing users to easily convert generator eigenvalues to the corresponding frequency spectrum.

• A utility function, frequencies_to_period, is provided, allowing users to determine the period of f(t) = <0|U(t)† O U(t)|0> given the frequencies of G (where U(t) = exp(iGt)).

• generate_shift_rule can now be used to return iterated shift rules that return higher order derivatives of an operator (e.g., ∂^2 f/∂t^2

• generate_multi_shift_rule can now be used to return iterated shift rules that return higher order derivatives of multiple operators (e.g., ∂^(n+m) f / ∂x^n ∂y^m). This can be used to generate shift rules for the off-diagonal elements of Hessians.

• CommutingEvolution has been updated to take into account these changes.

Benefits:

• It is now possible to query for shift rules of multiple operations, to arbitrary order.

• It is easier to understand the output of generate_shift_rules.

Possible Drawbacks: n/a

Related GitHub Issues: n/a

[mariaschuld]

I think I need a bit more explanation here, are those gates like U(theta1) U(theta2)?

[josh146]

yes, exactly!

[mariaschuld]

I am not sure I understood and checked all details, but what would help me a lot is if the docstrings would translate jargon to actual data structures (i.e. an array of shifts for parameter shift rules). I think they don't need to go deep, but at the moment they use a lot of terms that have no meaning to an outsider.

The small functions look otherwise very useful!

A quick general question: since we push this into the release, are we sure the names and functionality will stay like this, or is there an uncertainty?

Other than that, are we not testing the dispatch/math methods? (I forgot)

So not a strong "request changes", happy to accept asap!

[dwierichs]

Very nice set of utility functions! This looks super cool to use already and I'm exited to start using them.
Regarding the frequencies_to_period utility, we should either adapt the docstring or modify it to use the greatest common divisor (GCD) instead of f_min.

For the docstring of the multi shift rule I might have misunderstood something, but if not, I made a couple of suggestions there as well :)

[josh146]

Thanks @mariaschuld @dwierichs! Your comments were super helpful. I've implemented every one. Two of the biggest changes are:

• I've removed the term 'gradient recipe' everywhere, as I realize this is technical jargon that makes it harder for external developers. Instead, I've replaced it with 'gradient rule', which should be more familiar due to 'parameter-shift rule'.

• I've updated frequencies_to_period to use np.gcd, and added tests for non-equidistant frequencies 🙂

[mariaschuld]

The frequencies of an operator are not a standard term. I fear we have to link to something where people can find an explanation? Or say "frequencies (i.e., the unique differences of any two eigenvalues)"

Sorry for not picking this up before

[josh146]

Good point, I suppose we use it as a shortcut for

Fourier-series frequencies of the function f(t) = <0|U(t)† O U(t)|0>, for some observable O where U(t)=exp(iHt).

[josh146]

@mariaschuld I've updated the changelog here: 680164c Let me know if that reads better!

[mariaschuld]

I'm approving to fast-track, but consider implementing the wording changes in the changelog!

I think "frequencies of an operator" is a Xanadu-only term :)

[dwierichs]

Happy to approve! The only open thing from my perspective is the simplification to skip abs in eigvals_to_frequencies but that's also a tiny detail and no blocker.