Add get_best_diff_method and _get_gradient_fn to qml.workflow

[andrijapau]

Context:

Right now, QNode.get_gradient_fn and QNode.get_best_method, and QNode.best_method_str all exist as public or static methods and aren't used internally (aside from inside the QNode class) and they don't make much sense externally. To address this, a new user-friendly function should be added.

Description of the Change:

Implemented functions get_best_diff_method and _get_gradient_fn to qml.workflow. They behave the same as the existing methods in QNode but are designed with a simpler interface in mind 😄. The former is intended to be more user-facing and so has a simplifed interface. The latter is more for internal development and will be used to deprecate the internal QNode methods mentioned earlier.

For get_best_diff_method the user can provide the QNode they are trying to execute and it will return a string with the "best" differentiation method.

For _get_gradient_fn, the intention was to extract this from QNode and use it later on once we begin the deprecation and removal of those methods outlined earlier.4

Example

qml.workflow.get_best_diff_method

>>> dev = qml.device("default.qubit")
>>> qn = qml.QNode(lambda: None, dev)
>>> qml.workflow.get_best_diff_method(qn)()
'backprop'
>>> dev_shots = qml.device("default.qubit", shots=45)
>>> qn_shots = qml.QNode(lambda: None, dev_shots)
>>> qml.workflow.get_best_diff_method(qn_shots)()
'parameter-shift'

qml.workflow._get_gradient_fn

>>> qml.workflow._get_gradient_fn(dev_shots, diff_method='parameter-shift')
<transform: param_shift>

Benefits: Improves QNode organization and structure.

Possible Drawbacks: None

[sc-72157]

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.38%. Comparing base (cc80809) to head (35ec3b2).
Report is 2 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #6399      +/-   ##
==========================================
- Coverage   99.70%   99.38%   -0.32%     
==========================================
  Files         448      450       +2     
  Lines       42566    42619      +53     
==========================================
- Hits        42441    42359      -82     
- Misses        125      260     +135     

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

[albi3ro]

Thanks for putting this together.

My thoughts now are:

Do users care at all about the transform version of a diff method specification? Or would they just care about the string specification?

I'm leaning to strictly returning the string variant for now. get_best_diff_method is not intended to be used as part of the core workflow, but a way for users to inspect the workflow.

As for converting the string spec to a gradient transform, I think that could probably happen during a new resolve_execution_config developer function.

[albi3ro]

Sorry to update this at this point, but I'm not entirely sure if we need a public get_gradient_fn function.

Who would be the main consumer for this variant? If users, we would probably want the interface to be more user friendly. If developers, we can make it private _get_gradient_fn, and thus be able to change any of the code as need be.

Yes, we end up in a situation where we are deprecating QNode.get_gradient_fn without a true alternative, but I think QNode.diff_method combined with get_best_diff_method are sufficient replacements.

[albi3ro]

🚀

[astralcai]

🚀