-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Expand DEFCIRCUIT #373
Comments
cc: @mhodson-rigetti @bramathon - you may be interested in following this issue. |
I can think of cases when you might want the precedence order to be one or the other, but it is perhaps more common to have DEFCAL take precedence over DEFCIRCUIT. |
We'd like the behaviour to be as follows: If a DEFCAL is found for the instruction, then it should be expanded. If no DEFCAL is found, but a DEFCIRCUIT is, expand the DEFCIRCUIT to its sequence of sub-instructions and expand their sub-instructions to DEFCALs. Convention is that DEFCIRCUIT should contain only logical instructions, not quil-t. The reason to do it this way is so that we can define calibrations for logical subcircuits, which may differ in important ways from the calibrations of individual instructions. If the user doesn't desire to use the DEFCAL associated with a DEFCIRCUIT, this is relatively easy to achieve. Simply remove the DEFCAL, reference the individual instructions rather than the DEFCIRCUIT, or expand the DEFCIRCUIT prior to translation. To this end, I suggest the addition of and expand_defcircuit method. |
DEFCIRCUIT should be expended in much the same way as DEFCAL. DEFCIRCUIT expansion should be a distinct process from DEFCAL so as to make their ordering explicit. This is important because a gate may match both a DEFCIRCUIT and a DEFCAL and the Quil spec does not dictate which has precedence.
The text was updated successfully, but these errors were encountered: