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

Investigate specialization/generalization #483

Open
jvansomeren opened this issue May 5, 2023 · 1 comment
Open

Investigate specialization/generalization #483

jvansomeren opened this issue May 5, 2023 · 1 comment

Comments

@jvansomeren
Copy link
Collaborator

A gate may have values for an attribute that depend on the particular qubit index of an operand. The configuration specification supports specifying this, and thus at some time during compilation, one wants to specialize a gate application as far as possible to get the operand dependent attribute values. An example is the duration attribute of a gate.
Currently in OpenQL, this is an action: to turn the gate application in its specialized form, or even back into its generalized form. What you would want is an interface that an attribute values retrieval would check operand index values to find the proper attribute value. I.e. we get rid of this state of being in specialized or generalized form. In OpenQL, qubit operands always have an index value, but in case that would not be so, then an undefined index value could lead to an undefined attribute value (or the largest of all, or the smallest of all but that requires too much specs).
This would also simplify the IR: one step further into the direction that the acceptance of an IR to a pass doesn't depend on some state (another example is qubits being virtual or real).

@jvansomeren
Copy link
Collaborator Author

jvansomeren commented May 28, 2023

The reference updater include/ql/com/map/reference_updater.h and its source src/ql/com/map/reference_updater.cc update in an instruction (includes a gate) the qubit operand(s) from virtual to real, i.e. applies the qubit mapping, when the gate has just been mapped.
The code states that this assumes that the gates are in the generalized form (since virtual qubits are all equal, not hardware bound, and need not nearest-neighbor).
And after this reference updating, it turns the gate in its specialized form; this can be done since the qubits are real now.

But why is the gate brought in its specialized form during mapping?
For one thing, it is the first opportunity to do this since the qubits just became real.
It allows for different gate descriptions for virtual operands and for real operands.
Perhaps gates, while being mapped, are automatically specialized, and is specialized just the gate form for real qubits; so generalized/specialized is coupled to virtual/real.

Without mapping, all qubits are NN, and all qubits are virtual AND real; then having the difference is not necessary; this would explain why both specialized and generalized are there: a choice could not be made. Without mapping, I see no reason for the generalized form when there is also a specialized form; so generalized without specialized is ok but with not.
With mapping, it is also ok when there is no specialized form because then the generalized form applies to real qubits as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant