You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In issue #897 around Qiskit 2.0 support I wrote a comment that there are also circuit library deprecations that should be addressed #897 (comment)
Qiskit ML both uses library circuits like this and also has its own library with BlueprintCircuit based circuits (QNNCircuit and RawFeatureVector). Now BlueprintCircuit is not yet deprecated (is expected to be) but classes in Qiskit derived from this that are used here, such as ZZFeatureMap have already been deprecated since Qiskit 1.3 and their replacement is a function creating an equivalent circuit. Logically it makes sense to do the same with circuit library instances in ML. Now I will note that an aspect of BlueprintCircuit was it allowed a circuit template/design to be specified but without knowing the number of qubits at that point. I.e you might have a high level application input that gets mapped down and without running the mapping the number is not known, but nevertheless an appropriate circuit template for the problem can still be chosen with the circuit being actually built later when known. Now I do not think that aspect is (much) used in ML here the functions require the number of qubits to be given so the circuit is created but I think this should therefore not be an issue in general.
So this has two aspects;
Rework ML code/test/tutorials etc using BlueprintCircuit based Qiskit circuit library classes, such as ZZFeatureMap etc, to use the replacement functions.
Update the ML circuit library classes, and their usage here, similarly.
I will note that this is a place where the number of qubits is attempted to be set and an error raised if it can't be
I guess this code will just raise an error going forwards if there is a size mismatch and not attempt to set num_qubits since that setter, for a plain circuit, will not be there anymore, There may be other places too I did not look in depth.
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
In issue #897 around Qiskit 2.0 support I wrote a comment that there are also circuit library deprecations that should be addressed #897 (comment)
Qiskit ML both uses library circuits like this and also has its own library with BlueprintCircuit based circuits (QNNCircuit and RawFeatureVector). Now BlueprintCircuit is not yet deprecated (is expected to be) but classes in Qiskit derived from this that are used here, such as ZZFeatureMap have already been deprecated since Qiskit 1.3 and their replacement is a function creating an equivalent circuit. Logically it makes sense to do the same with circuit library instances in ML. Now I will note that an aspect of BlueprintCircuit was it allowed a circuit template/design to be specified but without knowing the number of qubits at that point. I.e you might have a high level application input that gets mapped down and without running the mapping the number is not known, but nevertheless an appropriate circuit template for the problem can still be chosen with the circuit being actually built later when known. Now I do not think that aspect is (much) used in ML here the functions require the number of qubits to be given so the circuit is created but I think this should therefore not be an issue in general.
So this has two aspects;
I will note that this is a place where the number of qubits is attempted to be set and an error raised if it can't be
qiskit-machine-learning/qiskit_machine_learning/kernels/base_kernel.py
Line 114 in ef44f5a
The text was updated successfully, but these errors were encountered: