-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Circuit drawer is illegible for instructions with circuit parameters. #9908
Comments
I agree that this isn't great, but what's the use-case for putting a edit: fwiw, I think it might be cleaner if we have a list of parameter types that we allow drawing rather than a list that we skip, but it would be tricky to ensure that we don't introduce regressions if we do that. |
I am using it for intermediate instructions ins some complicated custom transpilation where i want to store a circuit block in an instruction for use later, and where i might want to transpile/modify that block while it is in the instruction in subsequent passes. I tried doing this with a ControlFlowOp subclass but that doesnt work because DAGCircuit hard codes allowed ControlFlowOp subclasses. So it was easier to just make a regular Instruction subclass, but that leads to the current issue. I like the idea of having allowed param values for printing though so they only get printed if numeric (int/float/complex) or string, and disable casting via |
Ok yeah, that sounds fair as a current limitation. I'm interested in expanding the allowed "block" constructs in the future to include a nestable "basic block", but right now it's not a top priority and if your custom instruction just about works then that's ok. For the allowed parameter types: off the top of my head, the list of types we'd need to accept would be at least instances of An alternative strategy (that I'm not sure how I feel about) would be to attempt to |
Hi @jakelishman. can I help with this? |
Hi Diego, yeah absolutely, thanks! I'll assign you, and feel free to ask questions. |
Thanks @jakelishman, I created a PR with a fix for this specific issue, but let me know if you would like to add any of the other items you described above. |
Sorry I didn't immediately respond here - I saw that you'd had a review on the other PR that you were going to do something with, so I'd left that. The direction you're going on that PR makes sense to me. |
Environment
What is happening?
If I try and make an instruction containing a quantum circuit as a parameter, the circuit drawer attempts to draw the contained circuit as the parameter value leading to an illegible drawing. Examples of such instructions are ControlFlowOps, thought these are treated as a special case in the drawer code.
How can we reproduce the issue?
shows
What should happen?
Skip attempting to add parameter values to the drawing if parameters are circuits. This would also remove requiring a special case in the drawer code for ControlFlowOps, as they would just be handled by the general case of circuit parameters.
Eg, the above example should draw as
Any suggestions?
Change the
get_param_str
method to also skip QuantumCircuit parameters (it currenlty just skips ndarray parameters).The text was updated successfully, but these errors were encountered: