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

Slicing on classical registers #250

Open
vmartinv opened this issue Dec 29, 2021 · 3 comments
Open

Slicing on classical registers #250

vmartinv opened this issue Dec 29, 2021 · 3 comments

Comments

@vmartinv
Copy link

vmartinv commented Dec 29, 2021

I'm trying to write code in QASM 3 and this is the only compiler I found. I'm having problems with slicing classical registers as shown below:

OPENQASM 3;

bit c[8]="01010101";
print(c[0:4]);

gives me:

bash-5.1$ qcor -qpu aer -shots 1  test.qasm -o test

[OPENQASM3 MLIRGen] cannot parse the source.
error: no viable alternative at input 'print(c[0:'
occurred at test:3:9, offending symbol = :

[qcor-exec] fatal error.

Am I doing something wrong?

Using let it seems that it somehow thinks is a qubit array:

OPENQASM 3;

bit c[8]="01010101";
let slice = c[0:4];
print(slice);

gives me:

bash-5.1$ qcor -qpu aer -shots 1  test.qasm -o test

[OPENQASM3 MLIRGen] Error
Could not infer qubit[] size from block argument. No size attribute for variable in symbol table.

[qcor-exec] fatal error.

I don't know if I'm making something wrong or if there's an error in qcor.

@ausbin
Copy link
Contributor

ausbin commented Jan 5, 2022

Are either of these supported by OpenQASM 3?

Looking at the official grammar, it seems the slicing with : is only present in rangeDefinition which cannot be produced from an expression, and arguments to subroutines must be expressions. So the last line of the following doesn't seem to be syntactically valid:

OPENQASM 3;
bit c[4] = "0101";
print(c[1:2]);

Regarding using aliasing with a classical register, it seems like valid syntax according to the grammar, but I noticed the OpenQASM 3 spec currently says (emphasis mine):

The let keyword allows quantum bits and registers to be referred to by another name as long as the alias is in scope.

Notice that it doesn't say anything about classical registers.

I'm not sure if I'm taking the (living) spec too literally, and I'm not trying to argue against supporting this, just my thoughts

@vmartinv
Copy link
Author

vmartinv commented Mar 1, 2022

@ausbin

Looking at the official grammar, it seems the slicing with : is only present in rangeDefinition which cannot be produced from an expression, and arguments to subroutines must be expressions. So the last line of the following doesn't seem to be syntactically valid:

c[1:2] it's a valid expression, the expansion is as follows:
expression -> unaryExpression -> powerExpression -> indexExpression -> indexExpression indexOperator ->* Identifier LBRACKET rangeDefinition RBRACKET ->* etc

The let keyword allows quantum bits and registers to be referred to by another name as long as the alias is in scope.

Notice that it doesn't say anything about classical registers.

Exactly, it doesn't say anything about classical registers so the grammar becomes our only source of truth, thus the expression is valid if we're being logical. Specifically, it says "let keyword allows X" and not "let keyword only allows X". On top of that I think the correct reading is: "(quantum bits) and registers". From the common sense side, this should be supported.

@ausbin
Copy link
Contributor

ausbin commented Mar 2, 2022

You're right, thanks for correcting my misunderstanding of the official grammar. However, I don't think the grammar in the qcor parser supports that:

: unaryOperator expressionTerminator
(compare with https://github.com/Qiskit/openqasm/blob/3bba89ab69c440934663af55d139890a4569311f/source/grammar/qasm3.g4#L391)

So it seems to me like the grammar in this repository needs to be updated (which I assume will require updating the visitor that walks the parse tree, oh boy)

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

2 participants