Skip to content
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

Proposed DEFCAL semantics incompatible with current DEFGATE / DEFCIRCUIT semantics #17

Open
braised-babbage opened this issue Aug 15, 2019 · 0 comments
Assignees
Labels
2024.1 Changes for the 2024.1 specification.

Comments

@braised-babbage
Copy link
Contributor

braised-babbage commented Aug 15, 2019

For DEFGATE and DEFCIRCUIT, the order of definitions is irrelevant; if there are multiple top-level definitions the behavior at gate/circuit application is undefined. As discussed elsewhere, this is convenient for the parser, since it does not need to keep positions of definitions and can worry about name resolution after parsing raw quil.

The proposed DEFCAL semantics:

Calibrations can be parameterized and include concrete values, which are resolved in "Haskell-style", with later definitions being prioritized over earlier ones.

This is incompatible with the current machinery.

Here are a few options:

  • The behavior is undefined when there are multiple DEFCAL with the same name. personally, I think this is too strict.

  • We adopt the last-to-first convention, but behavior is only well-defined if all DEFCAL are in the same .quil file. This is workable but feels like a hack.

  • We adopt something like a most-specific-first convention, where calibration definitions are ordered by the number of constant params/args, ordered left-to-right, and the behavior is otherwise ill-specified.

To elaborate on the latter:
RX(pi/2) 0
could match (ordered by priority):

DEFCAL RX(pi/2) 0: 
    ...
DEFCAL RX(%theta) 0:
    ...
DEFCAL RX(pi/2) %theta:
    ...
DEFCAL RX(%theta) %qubit:
    ...

regardless of the position of these declarations in the source file.

@stylewarning stylewarning self-assigned this Feb 15, 2024
@stylewarning stylewarning added the 2024.1 Changes for the 2024.1 specification. label Feb 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2024.1 Changes for the 2024.1 specification.
Projects
None yet
Development

No branches or pull requests

2 participants