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
It would be great to make the gate-set configurable and offer more options.
Describe the solution you'd like
Interface-wise, the verify_compilation method would just receive an additional parameter that defaults to the new IBM gate-set and can optionally be set to a different gate-set.
Most certainly, it will make sense to introduce a Python Enum that specifies the available gate-sets.
This way, it can be ensured that pre-generated profiles for all combinations are available.
An alternative, that might require a little bit more work, would be to allow arbitrary gate sets (just as the transpile method in Qiskit takes an arbitrary list of strings`). Whenever a pre-generated profile is available for the given gate-set, it can directly be used. When that is not the case, there are multiple options: either abort and prompt the user to generate the profile locally once, or automatically generate the profile on the first invocation (emitting a warning that this requires additional time; once).
At the very least, the old IBM gate-set ("id", "u1", "u2", "u3", "cx") should be added to the list of available options.
Probably it would also make sense to include the Rigetti gate set ("rx", "rz", "cz", "measure").
Overall it should be easy to adapt the profile generation code to additionally take a gate-set as a parameter that is being passed through to the transpile call.
The text was updated successfully, but these errors were encountered:
What's the problem this feature will solve?
At the moment, the dedicated strategy for verifying the results of quantum circuit compilation flows inherently assumes that the target gate set is IBM's modern gate-set (
CX, ID, RZ, SX, X
), i.e., the profiles generated by https://qcec.readthedocs.io/en/latest/library/VerifyCompilation.html#compilation-flow-profile-generation only work reliably well for circuits compiled to that gate-set.It would be great to make the gate-set configurable and offer more options.
Describe the solution you'd like
Interface-wise, the
verify_compilation
method would just receive an additional parameter that defaults to the new IBM gate-set and can optionally be set to a different gate-set.Most certainly, it will make sense to introduce a Python Enum that specifies the available gate-sets.
This way, it can be ensured that pre-generated profiles for all combinations are available.
An alternative, that might require a little bit more work, would be to allow arbitrary gate sets (just as the
transpile
method in Qiskit takes an arbitrary list of strings`). Whenever a pre-generated profile is available for the given gate-set, it can directly be used. When that is not the case, there are multiple options: either abort and prompt the user to generate the profile locally once, or automatically generate the profile on the first invocation (emitting a warning that this requires additional time; once).At the very least, the old IBM gate-set (
"id", "u1", "u2", "u3", "cx"
) should be added to the list of available options.Probably it would also make sense to include the Rigetti gate set (
"rx", "rz", "cz", "measure"
).Overall it should be easy to adapt the profile generation code to additionally take a gate-set as a parameter that is being passed through to the
transpile
call.The text was updated successfully, but these errors were encountered: