Skip to content

Docs: Clarify lack of adjoint/MCM support in default.qubit #7365

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

KaranSinghDev
Copy link

Context:
While testing device capabilities using default.qubit (with a recent dev version installed via pip), I observed through the device.capabilities property and test execution that adjoint differentiation and native mid-circuit measurements are not supported. This information wasn't immediately obvious in the main docstring for the device.

Description of the Change:
This PR adds two small .. note:: blocks to the class docstring of pennylane.devices.DefaultQubit (in pennylane/devices/default_qubit.py).

  • The first note clarifies that diff_method="adjoint" is not supported.
  • The second note clarifies the limitations of mid-circuit measurement support on this device.

(Note: The PR template requests adding an entry to doc/releases/changelog-dev.md, but this file does not currently exist in the master branch. No changelog entry has been added as the correct location is unclear.)

Benefits:
Improves documentation clarity for default.qubit users, helping them quickly understand the device's limitations regarding adjoint differentiation and mid-circuit measurements without needing to run tests or dig deep into code/capabilities dictionaries. This prevents potential confusion.

Possible Drawbacks:
None anticipated for this documentation clarification.

Related GitHub Issues:
None.

@github-actions github-actions bot added the external PRs where the author is not a part of PennyLane Org (or part of external contributors team) label May 1, 2025
Copy link
Contributor

@albi3ro albi3ro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for opening this PR @KaranSinghDev .

Mind sharing what workflows you were trying that were getting errors? It might even be worth opening a bug report issue.

@KaranSinghDev
Copy link
Author

Hi @albi3ro , thanks for the review and your response!

No specific complex workflow errored out unexpectedly. This change came about during general testing where I specifically checked the capabilities of default.qubit.

After verifying via device.capabilities that Adjoint Differentiation and Mid-Circuit Measurements were reported as unsupported, I thought it would be helpful to add explicit notes about these limitations to the main docstring for better user clarity upfront.

It didn't seem like a bug in the features themselves, just an opportunity to improve the documentation based on the device's reported capabilities. Let me know if you need more info!

@albi3ro
Copy link
Contributor

albi3ro commented May 2, 2025

DefaultQubit relies on its own implementations for preprocess, rather than relying on a default implementation created from a capabilities spec, as that gives us greater control and flexibility over what is supported when.

It should be able to support adjoint and native mid circuit measurements, so if that's not the case, that is a bug we need to fix.

But I would agree that the docstring for DefaultQubit could use a major rewrite to make it more user facing, rather than what it is right now.

@KaranSinghDev
Copy link
Author

Thanks for the clarification regarding DefaultQubit's custom preprocess implementation – that makes sense!

It's interesting that it should support Adjoint and native MCM. In the testing I ran (using the 0.42.0-dev18 version installed via pip install pennylane), the device.capabilities check returned False for both supports_adjoint_differentiation and supports_mid_measure after I corrected how the dictionary was accessed.

Given your confirmation that these should be supported, this discrepancy definitely sounds like something worth investigating further – potentially a bug or perhaps an issue specific to the development version.

I'm happy to open a new bug report issue detailing the test environment (Kaggle notebook, Python 3.11, PL 0.42.0-dev18), the test script used, and the output showing the capabilities check results.

Does that sound like the best way forward? If so, I agree it probably makes sense to close this documentation PR (#7365 ) for now, as the notes are based on the currently observed (but potentially incorrect) capability reporting.

I agree the docstring could use a rewrite eventually, and I'd be happy to help anyway with that once the Adjoint/MCM status is confirmed/fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
external PRs where the author is not a part of PennyLane Org (or part of external contributors team)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants