amazon-braket / amazon-braket-default-simulator-python

Quantum program simulators that can run locally
https://amazon-braket-default-simulator-python.readthedocs.io/
Apache License 2.0
67 stars 22 forks source link

fix: cast node.size to IntegerLiteral for qubit register size #263

Open rmshaffer opened 5 months ago

rmshaffer commented 5 months ago

Issue #, if available:

240

Description of changes: Starting with the changes from #258 and performing the additional work required to merge to main.

The biggest outstanding items are:

Testing done: tox

Merge Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your pull request.

General

Tests

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

EuGig commented 5 months ago

@rmshaffer, @DanBlackwell Maybe we should rethink the following case test:

bit[3] b;
qubit["10"] r1;
h r1["01" << "01"];

In this regard the spec explicitly states that shifting, either right or left, is supported by an unsigned integer (https://openqasm.com/language/classical.html#classical-bits-and-registers). Shifting by a bitstring causes a strange behaviour in case its length does not match the length of the specified qbuit array:

bit[3] b;
qubit[3] r1;
h r1["01" << "01"];
IndexError: boolean index did not match indexed array along dimension 0; dimension is 3 but corresponding boolean dimension is 2

Since we are enabling registers sizes to be specified also as bitstring, maybe we should raise an error if the LHS is also a bitstring. This influences the refactoring since, it pertains code regarding shifting operations.

DanBlackwell commented 5 months ago

Maybe slightly related, but I found the following here the other day:

image

I'm not sure whether this is implying that it is valid to cast an array of bits into int and vice versa; but in that case I think that when applying any ops (+ - << >> | & ^ etc) to an 'array of bits' (which a 'bit string literal' is afaik) the best approach is to cast to 'int' rather than reimplement them (and cast back if required). I'm not sure how integer over- and underflows are meant to be handled though.