Closed edoaltamura closed 1 week ago
We'll need to add Reno files before the merge. > Done.
From above:
Deprecation of V1 Primitives: This update serves as a transitional support for V1 primitives, which will be deprecated and removed in version 0.9. Users should prepare to migrate fully to V2 primitives to ensure future compatibility.
V1 primitives in Qiskit and Aer are already deprecated in the latest current versions of these. Do you want to issue a deprecation message at this level from ML if the QNN is provided a V1 estimator to state its use is deprecated for ML and to use V2 instead. Yes I would imagine this will be noted in the reno that is yet to be added but having the messages emitted from the code is normally done too. Yes a user would see a couple of messages in this case, one from ML and one from Qiskit/Aer around deprecation of V1, but maybe that'll just reinforce that the user should really be using V2 versions.
With V1 primitives usage being deprecated are you going to swap the notebooks/tutorials over to using V2 which ideally a user should be using now - I did not see any updated by this PR hence this comment
With V1 primitives usage being deprecated are you going to swap the notebooks/tutorials over to using V2 which ideally a user should be using now - I did not see any updated by this PR hence this comment
Hi Steve, we are planning to swap the notebooks/tutorials after deprecating V1.
V1 primitives in Qiskit and Aer are already deprecated in the latest current versions of these. Do you want to issue a deprecation message at this level from ML if the QNN is provided a V1 estimator to state its use is deprecated for ML and to use V2 instead. Yes I would imagine this will be noted in the reno that is yet to be added but having the messages emitted from the code is normally done too. Yes a user would see a couple of messages in this case, one from ML and one from Qiskit/Aer around deprecation of V1, but maybe that'll just reinforce that the user should really be using V2 versions.
We thought about this but there are already enough deprecation warnings from Qiskit/Aer/Runtime.
I am not sure I understand exactly
we are planning to swap the notebooks/tutorials after deprecating V1.
V1 primitives are already deprecated - with the V2 being supported now ideally those notebooks should be using V2. Even if you issue no deprecation messages from ML logically the support for V1 is being deprecated now with 0.8 with the intent to remove it completely in 0.9, Hence the notebooks being changed now for 0.8 to me logically is still after the V1 support is deprecated. Even if its not part of this PR I would think it would be done for 0.8, no?
I am not sure I understand exactly
we are planning to swap the notebooks/tutorials after deprecating V1.
V1 primitives are already deprecated - with the V2 being supported now ideally those notebooks should be using V2. Even if you issue no deprecation messages from ML logically the support for V1 is being deprecated now with 0.8 with the intent to remove it completely in 0.9, Hence the notebooks being changed now for 0.8 to me logically is still after the V1 support is deprecated. Even if its not part of this PR I would think it would be done for 0.8, no?
Due to time constraints, what about doing it in minor updates through 0,8?
We thought about this but there are already enough deprecation warnings from Qiskit/Aer/Runtime.
v1 has long gone from Runtime. It could always be arranged, with some global flag that was set once a deprecation was issued, to make the message conditional on this flag not being set such that at least one message gets emitted by ML such people are aware of this. They would have been seeing deprecation messages for some time from Qiskit and Aer and may just kinda ignore them by now such that unless they read the release notes for 0.8 they will have no idea. If it were me I would have the messages in their unconditionally such that if they find it noisy it encourages a switch to V2 which they should be using now right!
Due to time constraints, what about doing it in minor updates through 0,8?
Notebooks are part of docs and docs can be republished at any time independent of a release. Hopefully they work right still with the V2 changes - in my mind having them updated would have ensured this. They would get updated and backported and the docs republished - simple as that, no version change needed as such since no new package would get released as they are are not part of what gets published to pypi - just part of the docs.
From above:
Deprecation of V1 Primitives: This update serves as a transitional support for V1 primitives, which will be deprecated and removed in version 0.9. Users should prepare to migrate fully to V2 primitives to ensure future compatibility.
V1 primitives in Qiskit and Aer are already deprecated in the latest current versions of these. Do you want to issue a deprecation message at this level from ML if the QNN is provided a V1 estimator to state its use is deprecated for ML and to use V2 instead. Yes I would imagine this will be noted in the reno that is yet to be added but having the messages emitted from the code is normally done too. Yes a user would see a couple of messages in this case, one from ML and one from Qiskit/Aer around deprecation of V1, but maybe that'll just reinforce that the user should really be using V2 versions.
I just added the deprecation warnings in the top-level classes.
Changes Missing Coverage | Covered Lines | Changed/Added Lines | % | ||
---|---|---|---|---|---|
qiskit_machine_learning/gradients/param_shift/param_shift_estimator_gradient.py | 32 | 33 | 96.97% | ||
qiskit_machine_learning/state_fidelities/compute_uncompute.py | 36 | 39 | 92.31% | ||
qiskit_machine_learning/neural_networks/estimator_qnn.py | 27 | 31 | 87.1% | ||
qiskit_machine_learning/neural_networks/sampler_qnn.py | 26 | 30 | 86.67% | ||
qiskit_machine_learning/algorithms/inference/qbayesian.py | 20 | 28 | 71.43% | ||
qiskit_machine_learning/utils/deprecation.py | 7 | 15 | 46.67% | ||
qiskit_machine_learning/gradients/param_shift/param_shift_sampler_gradient.py | 10 | 27 | 37.04% | ||
<!-- | Total: | 173 | 218 | 79.36% | --> |
Files with Coverage Reduction | New Missed Lines | % | ||
---|---|---|---|---|
qiskit_machine_learning/neural_networks/sampler_qnn.py | 1 | 92.68% | ||
<!-- | Total: | 1 | --> |
Totals | |
---|---|
Change from base Build 11647663594: | -0.5% |
Covered Lines: | 4765 |
Relevant Lines: | 5224 |
Introduction
This PR introduces support for V2 Primitives within the
EstimatorQNN
andSamplerQNN
high-level classes, resolving compatibility issues for users running experiments on Qiskit IBM Runtime real backends. The addition enables transitioning between local simulations with V1 primitives and hardware executions with V2 primitives, meeting the new requirements for Qiskit Runtime ISA circuits.Problem description
EstimatorQNN
andSamplerQNN
default to Estimator and Sampler fromqiskit.primitives
, which only supports V1 primitives. However, Qiskit IBM Runtime requires V2 primitives (introduced in Qiskit Machine Learning 0.8.0) to run jobs on real quantum backends. Using the V1 primitives results in runtime errors because they are incompatible with Qiskit Runtime’s requirements for structured Primitive Unified Blocks (PUBs) and ISA circuit format.Changes in This PR
Conditional support for V2 Primitives. Added a check in
EstimatorQNN
andSamplerQNN
to detect if a V2 primitive (EstimatorV2
orSamplerV2
) fromqiskit_ibm_runtime
is provided. If a V2 primitive is detected, the class will handle it automatically, allowing direct submission of circuits to hardware backends. The output of the jobs (both simulated and hardware) remains the same as before. For instance, where the output used to be quasi-probabilities, now the same quasi-probabilities are computed from the raw counts.Backward compatibility with V1 Primitives: Users can continue to use V1 primitives (e.g.,
SamplerV1
andEstimatorV1
) for local simulations with Qiskit Aer. This ensures that existing workflows are unaffected and that users can seamlessly transition to real backends by updating the backend and primitive definitions.Support for ISA Circuits: These updates ensure that circuits and observables are compatible with Qiskit Runtime’s ISA requirements. Added logic to handle circuit transpilation for ISA compatibility when using V2 primitives, with proper mapping of input and weight parameters, especially for composed feature maps and ansatz circuits.
Future considerations
Deprecation of V1 Primitives: This update serves as a transitional support for V1 primitives, which will be deprecated and removed in version 0.9. Users should prepare to migrate fully to V2 primitives to ensure future compatibility.
ISA circuit optimization: Further work may be needed to refine circuit transpilation and measurement processes for specific hardware constraints and optimize performance across different backends.
Details and comments
Fixes https://github.com/qiskit-community/qiskit-machine-learning/issues/742 Fixes https://github.com/qiskit-community/qiskit-machine-learning/issues/786 Fixes https://github.com/qiskit-community/qiskit-machine-learning/issues/810 Fixes https://github.com/qiskit-community/qiskit-machine-learning/issues/839 Fixes https://github.com/qiskit-community/qiskit-machine-learning/issues/840
Auxiliary issues closed: Fixes https://github.com/OkuyanBoga/hc-qiskit-machine-learning/issues/35
Related issues Algorithms: https://github.com/qiskit-community/qiskit-algorithms/issues/165 https://github.com/qiskit-community/qiskit-algorithms/issues/194 https://github.com/qiskit-community/qiskit-algorithms/issues/164 https://github.com/qiskit-community/qiskit-algorithms/issues/136 https://github.com/qiskit-community/qiskit-algorithms/issues/137
Related issues - others: https://github.com/qiskit-community/qiskit-finance/issues/338