Guide de migration des algorithmes#
En bref :#
Le module qiskit.algorithms
a été entièrement restructuré pour utiliser le primitives
, pour lβexΓ©cution du circuit, au lieu de QuantumInstance
, qui est désormais obsolète.
Il y a eu 3 types de refactoring :
Algorithmes refactorisΓ©s dans un nouvel emplacement pour supporter
primitives
. Ces algorithmes ont les mΓͺmes noms de classes que les classesQuantumInstance
correspondantes mais sont dans un nouveau sous-paquet.Attention
Attention aux chemins dβimportation!! Les algorithmes hΓ©ritΓ©s sont toujours importables directement depuis
qiskit.algorithms
. Tant que les importations hΓ©ritΓ©es ne sont pas supprimΓ©es, cette importation de commoditΓ© nβest pas disponible pour les algorithmes refactorisΓ©s. Ainsi, pour importer les algorithmes refactorisΓ©s, vous devez toujours spΓ©cifier le chemin complet dβimportation (par exemple,from qiskit.algorithms.eigensolvers import VQD
)Algorithmes refactorisΓ©s en place (mΓͺme espace de nom) pour prendre en charge les valeurs
QuantumInstance
etprimitives
. A lβavenir, lβutilisation deQuantumInstance
sera supprimée.Algorithmes dépréciés et maintenant entièrement supprimés de
qiskit.algorithms
. Ce sont des algorithmes qui ne servent pas actuellement de blocs de construction pour les applications. Leur valeur principale est Γ©ducative et, en tant que telle, sera conservΓ©e comme tutoriels dans le manuel de qiskit. Vous pouvez consulter les tutoriels dans les liens suivants :` Linear Solvers (HHL) <https://learn.qiskit.org/course/ch-applications/solving-linear-systems-of-equations-using-hhl-and-its-qiskit-implementation>` _,
` Factorizers (Shor) <https://learn.qiskit.org/course/ch-algorithms/shors-algorithm>` _
Le reste de ce guide de migration se concentrera sur les algorithmes avec des alternatives de migration au sein de :mod:` qiskit.algorithmes `, cβest-Γ -dire les algorithmes de restructuration des types 1 et 2.
Historique#
*Retour Γ la * ` TL; DR ` _
Le module :mod:` qiskit.algorithmesβa Γ©tΓ© construit Γ lβorigine sur la bibliothΓ¨que :mod:` qiskit.opflowβet lβutilitaire :class:` ~qiskit.utils.QuantumInstance. Le dΓ©veloppement des :mod:` ~qiskit.primitives a introduit un paradigme dβexΓ©cution de niveau supΓ©rieur, avec ` ` Estimateur ` ` pour le calcul des valeurs dβattente pour les observables, et ` ` Sampler ` ` pour lβexΓ©cution des circuits et les distributions de probabilitΓ© de retour. Ces outils ont permis de refacer le module :mod:` qiskit.algorithmes ` et dβen rendre compte Γ la fois :mod:` qiskit.opflow ` et :class:` ~qiskit.utils.QuantumInstance `.
Attention
La transition de :mod:` qiskit.opflow` affecte les classes que les algorithmes prennent dans le cadre de la configuration du problΓ¨me. En rΓ¨gle gΓ©nΓ©rale, la plupart des dΓ©pendances :mod:` qiskit.opflow` ont un remplacement direct :mod:` qiskit.quantum_info`. Un exemple commun est la classe :mod:` qiskit.opflow.PauliSumOp , utilisΓ©e pour dΓ©finir les hamiltoniens (par exemple, pour connecter VQE), qui peuvent Γͺtre remplacΓ©s par :mod: qiskit.quantum_info.SparsePauliOp`. Pour plus dβinformations sur la migration dβautres objets :mod:` ~qiskit.opflow`, vous pouvez vous rΓ©fΓ©rer au guide de migration Opflow <https://qisk.it/opflow_migration>` _.
Pour plus dβinformations sur lβarriΓ¨re-plan et les Γ©tapes de migration dΓ©taillΓ©es, voir:
Comment choisir une configuration primitive pour votre algorithme#
*Retour Γ la * ` TL; DR ` _
Les classes de qiskit.algorithmes
sont initialisΓ©es avec toute implΓ©mentation de qiskit.primitive.BaseSampler
ou :class: qiskit.primitive.BaseEstimator.
Une fois que le type de primitive est connu, vous pouvez choisir entre les implΓ©mentations primitives qui sβadaptent mieux Γ votre cas. Par exemple :
Pour le prototypage rapide, vous pouvez utiliser les implΓ©mentations de rΓ©fΓ©rence des primitives incluses dans Qiskit:
qiskit.primitives.Sampler
etqiskit.primitives.Estimator
.Pour lβoptimisation dβun algorithme plus fin, un simulateur local tel que lβimplΓ©mentation primitive dans Aer:
qiskit_aer.primitives.Sampler
etqiskit_aer.primitives.Estimator
.Pour lβexΓ©cution sur un ordinateur quantique, vous pouvez :
des services dβaccΓ¨s avec des implΓ©mentations primitives natives, telles que IBM Qiskit Runtime service via
qiskit_ibm_runtime.Sampler
etqiskit_ibm_runtime.Estimator
Enveloppez nβimporte quel backend avec Primitives Backend (
BackendSampler
etackendEstimator
). Ces encapsuleurs implΓ©mentent une interface primitive sur un backend qui ne supporte queBackend.run()
.
Pour des informations et des exemples plus dΓ©taillΓ©s, en particulier sur lβutilisation des ** Primitives Backend**, reportez-vous au guide de migration Quantum Instance.
In this guide, we will cover 3 different common configurations for algorithms that determine which primitive import you should be selecting:
Running an algorithm with a statevector simulator (i.e., using
qiskit.opflow
's legacyMatrixExpectation
), when you want the ideal outcome without shot noise:Reference Primitives with default configuration (see QAOA example):
from qiskit.primitives import Sampler, Estimator
Aer Primitives with statevector simulator (see QAOA example):
from qiskit_aer.primitives import Sampler, Estimator sampler = Sampler(backend_options={"method": "statevector"}) estimator = Estimator(backend_options={"method": "statevector"})
Running an algorithm using a simulator/device with shot noise (i.e., using
qiskit.opflow
's legacyPauliExpectation
):Reference Primitives with shots (see VQE examples):
from qiskit.primitives import Sampler, Estimator sampler = Sampler(options={"shots": 100}) estimator = Estimator(options={"shots": 100}) # or... sampler = Sampler() job = sampler.run(circuits, shots=100) estimator = Estimator() job = estimator.run(circuits, observables, shots=100)
Aer Primitives with default configuration (see VQE examples):
from qiskit_aer.primitives import Sampler, Estimator
IBMβs Qiskit Runtime Primitives with default configuration (see VQD example):
from qiskit_ibm_runtime import Sampler, Estimator
3. Running an algorithm on an Aer simulator using a custom instruction (i.e., using qiskit.opflow
's legacy
AerPauliExpectation
):
Aer Primitives with
shots=None
,approximation=True
(see TrotterQRTE example):from qiskit_aer.primitives import Sampler, Estimator sampler = Sampler(run_options={"approximation": True, "shots": None}) estimator = Estimator(run_options={"approximation": True, "shots": None})
Minimum Eigensolvers#
*Retour Γ la * ` TL; DR ` _
The minimum eigensolver algorithms belong to the first type of refactoring listed above
(Algorithms refactored in a new location to support primitives
).
Instead of a QuantumInstance
, qiskit.algorithms.minimum_eigensolvers
are now initialized
using an instance of the Sampler
or Estimator
primitive, depending
on the algorithm. The legacy classes can still be found in qiskit.algorithms.minimum_eigen_solvers
.
Attention
For the qiskit.algorithms.minimum_eigensolvers
classes, depending on the import path,
you will access either the primitive-based or the quantum-instance-based
implementation. You have to be extra-careful, because the class name does not change.
Old import (Quantum Instance based):
from qiskit.algorithms import VQE, QAOA, NumPyMinimumEigensolver
New import (Primitives based):
from qiskit.algorithms.minimum_eigensolvers import VQE, SamplingVQE, QAOA, NumPyMinimumEigensolver
VQE#
The legacy qiskit.algorithms.minimum_eigen_solvers.VQE
class has now been split according to the use-case:
For general-purpose Hamiltonians, you can use the Estimator-based
qiskit.algorithms.minimum_eigensolvers.VQE
class.If you have a diagonal Hamiltonian, and would like the algorithm to return a sampling of the state, you can use the new Sampler-based
qiskit.algorithms.minimum_eigensolvers.SamplingVQE
algorithm. This could formerly be realized using the legacyVQE
withCVaRExpectation
.
Note
In addition to taking in an Estimator
instance instead of a QuantumInstance
,
the new VQE
signature has undergone the following changes:
The
expectation
andinclude_custom
parameters have been removed, as this functionality is now defined at theEstimator
level.The
gradient
parameter now takes in an instance of a primitive-based gradient class fromqiskit.algorithms.gradients
instead of the legacyqiskit.opflow.gradients.Gradient
class.The
max_evals_grouped
parameter has been removed, as it can be set directly on the optimizer class.The
estimator
,ansatz
andoptimizer
are the only parameters that can be defined positionally (and in this order), all others have become keyword-only arguments.
Note
The new VQEResult
class does not include the state anymore, as
this output was only useful in the case of diagonal operators. However, if it is available as part of the new
SamplingVQE
βs SamplingVQEResult
.
For complete code examples, see the following updated tutorials:
QAOA#
The legacy qiskit.algorithms.minimum_eigen_solvers.QAOA
class used to extend
qiskit.algorithms.minimum_eigen_solvers.VQE
, but now, qiskit.algorithms.minimum_eigensolvers.QAOA
extends qiskit.algorithms.minimum_eigensolvers.SamplingVQE
.
For this reason, the new QAOA only supports diagonal operators.
Note
In addition to taking in an Sampler
instance instead of a QuantumInstance
,
the new QAOA
signature has undergone the following changes:
The
expectation
andinclude_custom
parameters have been removed. In return, theaggregation
parameter has been added (it used to be defined through a customexpectation
).The
gradient
parameter now takes in an instance of a primitive-based gradient class fromqiskit.algorithms.gradients
instead of the legacyqiskit.opflow.gradients.Gradient
class.The
max_evals_grouped
parameter has been removed, as it can be set directly on the optimizer class.The
sampler
andoptimizer
are the only parameters that can be defined positionally (and in this order), all others have become keyword-only arguments.
Note
If you want to run QAOA on a non-diagonal operator, you can use the QAOAAnsatz
with
qiskit.algorithms.minimum_eigensolvers.VQE
, but bear in mind there will be no state result.
If your application requires the final probability distribution, you can instantiate a Sampler
and run it with the optimal circuit after VQE
.
For complete code examples, see the following updated tutorials:
NumPyMinimumEigensolver#
Because this is a classical solver, the workflow has not changed between the old and new implementation.
The import has however changed from qiskit.algorithms.minimum_eigen_solvers.NumPyMinimumEigensolver
to qiskit.algorithms.minimum_eigensolvers.NumPyMinimumEigensolver
to conform to the new interfaces
and result classes.
For complete code examples, see the following updated tutorials:
Eigensolvers#
*Retour Γ la * ` TL; DR ` _
The eigensolver algorithms also belong to the first type of refactoring
(Algorithms refactored in a new location to support primitives
). Instead of a
QuantumInstance
, qiskit.algorithms.eigensolvers
are now initialized
using an instance of the Sampler
or Estimator
primitive, or
a primitive-based subroutine, depending on the algorithm. The legacy classes can still be found
in qiskit.algorithms.eigen_solvers
.
Attention
For the qiskit.algorithms.eigensolvers
classes, depending on the import path,
you will access either the primitive-based or the quantum-instance-based
implementation. You have to be extra-careful, because the class name does not change.
Old import path (Quantum Instance):
from qiskit.algorithms import VQD, NumPyEigensolver
New import path (Primitives):
from qiskit.algorithms.eigensolvers import VQD, NumPyEigensolver
VQD#
The new qiskit.algorithms.eigensolvers.VQD
class is initialized with an instance of the
Estimator
primitive instead of a QuantumInstance
.
In addition to this, it takes an instance of a state fidelity class from mod:qiskit.algorithms.state_fidelities,
such as the Sampler
-based ComputeUncompute
.
Note
In addition to taking in an Estimator
instance instead of a QuantumInstance
,
the new VQD
signature has undergone the following changes:
The
expectation
andinclude_custom
parameters have been removed, as this functionality is now defined at theEstimator
level.The custom
fidelity
parameter has been added, and the customgradient
parameter has been removed, as current classes inqiskit.algorithms.gradients
cannot deal with state fidelity gradients.The
max_evals_grouped
parameter has been removed, as it can be set directly on the optimizer class.The
estimator
,fidelity
,ansatz
andoptimizer
are the only parameters that can be defined positionally (and in this order), all others have become keyword-only arguments.
Note
Similarly to VQE, the new VQDResult
class does not include
the state anymore. If your application requires the final probability distribution, you can instantiate
a Sampler
and run it with the optimal circuit for the desired excited state
after running VQD
.
For complete code examples, see the following updated tutorial:
NumPyEigensolver#
Similarly to its minimum eigensolver counterpart, because this is a classical solver, the workflow has not changed
between the old and new implementation.
The import has however changed from qiskit.algorithms.eigen_solvers.NumPyEigensolver
to qiskit.algorithms.eigensolvers.MinimumEigensolver
to conform to the new interfaces and result classes.
Time Evolvers#
*Retour Γ la * ` TL; DR ` _
The time evolvers are the last group of algorithms to undergo the first type of refactoring
(Algorithms refactored in a new location to support primitives
).
Instead of a QuantumInstance
, qiskit.algorithms.time_evolvers
are now initialized
using an instance of the Estimator
primitive. The legacy classes can still be found
in qiskit.algorithms.evolvers
.
On top of the migration, the module has been substantially expanded to include Variational Quantum Time Evolution
(VarQTE
) solvers.
TrotterQRTE#
Attention
For the qiskit.algorithms.time_evolvers.TrotterQRTE
class, depending on the import path,
you will access either the primitive-based or the quantum-instance-based
implementation. You have to be extra-careful, because the class name does not change.
Old import path (Quantum Instance):
from qiskit.algorithms import TrotterQRTE
New import path (Primitives):
from qiskit.algorithms.time_evolvers import TrotterQRTE
Note
In addition to taking in an Estimator
instance instead of a QuantumInstance
,
the new VQD
signature has undergone the following changes:
The
expectation
parameter has been removed, as this functionality is now defined at theEstimator
level.The
num_timesteps
parameters has been added, to allow to define the number of steps the full evolution time is divided into.
Amplitude Amplifiers#
*Retour Γ la * ` TL; DR ` _
The amplitude amplifier algorithms belong to the second type of refactoring (Algorithms refactored in-place).
Instead of a QuantumInstance
, qiskit.algorithms.amplitude_amplifiers
are now initialized
using an instance of any « Sampler » primitive e.g. Sampler
.
Note
The full qiskit.algorithms.amplitude_amplifiers
module has been refactored in place. No need to
change import paths.
For complete code examples, see the following updated tutorials:
Amplitude Estimators#
*Retour Γ la * ` TL; DR ` _
Similarly to the amplitude amplifiers, the amplitude estimators also belong to the second type of refactoring
(Algorithms refactored in-place).
Instead of a QuantumInstance
, qiskit.algorithms.amplitude_estimators
are now initialized
using an instance of any « Sampler » primitive e.g. Sampler
.
Note
The full qiskit.algorithms.amplitude_estimators
module has been refactored in place. No need to
change import paths.
For complete code examples, see the following updated tutorials:
Phase Estimators#
*Retour Γ la * ` TL; DR ` _
Finally, the phase estimators are the last group of algorithms to undergo the first type of refactoring
(Algorithms refactored in-place).
Instead of a QuantumInstance
, qiskit.algorithms.phase_estimators
are now initialized
using an instance of any « Sampler » primitive e.g. Sampler
.
Note
The full qiskit.algorithms.phase_estimators
module has been refactored in place. No need to
change import paths.
For complete code examples, see the following updated tutorials: