-
Notifications
You must be signed in to change notification settings - Fork 677
Make the pipeline compatible with shots decoupling #7358
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
Conversation
Co-authored-by: Christina Lee <[email protected]>
|
This comment was marked as outdated.
This comment was marked as outdated.
Co-authored-by: Christina Lee <[email protected]>
Co-authored-by: Christina Lee <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Either in test_set_shots
to test_qnode
, can we add some tests where we use the device tracker to make sure we are choosing the best diff method appropriately?
For example, starting with a device with shots, the overriding to shots=None
, and double check we only have one execution when taking the gradient?
Or starting with shots=None
, overriding with finite shots, and checking we have 1+2*num_parameters executions when taking the derivative.
Done. Added in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your patience 👍 Looks good :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very satisfying, nice job! 🚀
Co-authored-by: Andrija Paurevic <[email protected]>
…cheme (#7461) **Context:** Besides `execution` (which has been already adjusted #7358 we still have another core helper `construct_batch` to be adjusted to follow the correct logic: *Before resolution of diff methods, apply all the user transforms* Previously, we have all the transforms computed after execution config resolution and also had something unclear to us called `final_transform`. Due to the new shot s setup system, the new transform `set_shots`, it is not valid any more to keep user transforms after the resolution stage; even from a pure performance point of view, it is not wise to carry out too much work that does not even need to be done if the level is specifically just "user" or a slice that range within `user` inclusively, because we just do not need this part of information processing and should have branched out way before. Specifcally, with `slice` being either `None` or `"top"`, our expectation for this batch constructor is actually there's no transform atl and it should do nothing (previously it is required to carry over the whole pipeline only because our deep coupling between `Shots` and `device`, so there's always a dilemma that one device could be either finite shot or analytic even if there's no transform atl so it requires resolution etc, which is already gone after the separation of these two concepts). **Description of the Change:** 1. `level`: we don't pass the value of `level` to other helpers anymore. Instead, we just use it as a normal immutable external inside `batch_constructor`. For certain special cases, the empty case (`None` and `"top"`) where we just do nothing and return, and the simple user case (`"user"` or int/slice that's completely inclusively within the range of user transforms) where we apply the transforms requested and immediately return, they will branch out without interfere with config resolution anymore. 2. lots of information indicators, mostly booleans, have been separately abstracted and extracted out of `batch_constructor`. They used to be used inside the following up helpers, secretly and fully encapsulated by other methods' interfaces. Now we just pre-process all of them, except those diff method related stuff. 3. For general slices, we just dynamically split the transforms into user and nonuser. Still all user transforms will be applied before resolution and the rest will be applied afterwards. We might need to ask ourselves if this is *compatible* with other packages. 4. Slightly refactored structure of `get_transform_program` by extracting the big chunk of level interpretation to a separate helper method. 5. Dropped VIP treatment for `final_transform`, and accordingly adjusted one test suite `test_final_transform` that was influenced by this change. **Benefits:** Much clearer pipeline to indicate `construct_batch` how ti works just within itself. Less redundant execution config processing. **Possible Drawbacks:** Way less OOP than before. However, due to the volatile essence of this part of pipeline, I guess being more procedural is some necessary evil. Also, i didn't change the `get_transform_program` since it's more like a self-contained public api now. **Related GitHub Issues:** [sc-91642] --------- Co-authored-by: Christina Lee <[email protected]> Co-authored-by: Isaac De Vlugt <[email protected]> Co-authored-by: Josh Izaac <[email protected]> Co-authored-by: Andrija Paurevic <[email protected]>
Context:
We want to:
qml.set_shots
orpartial(set_shots, shots=...)
works (the latter is the original requirement); ideally we wish it works for all interfaces and all shots/shot vecDescription of the Change:
Benefits:
Further clearance and decoupling for pipeline!
Possible Drawbacks:
Related GitHub Issues:
[SC-90145]