-
Notifications
You must be signed in to change notification settings - Fork 391
Description
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
| self._feature_map.num_qubits = x_vec.shape[1] |