Describe the bug
After some discussion here: https://github.com/Qiskit/qiskit/issues/12167, it seems that the stdgates.inc definition gate sx a { pow(1/2) @ x a; } should have the 1/2 resolve to 0 thanks to integer division (i.e. stdgates.inc has an incorrect definition of sx gate). As it stands, it seems that when interpreting openQASM 3, the Braket sim treats these values as floats (which makes that sx gate definition behave correctly). Apparently the relevant part of the specification is here: https://openqasm.com/language/classical.html#integers.
Being as 'fixing' this would break stdgates.inc as of right now, I don't think it should be 'fixed' yet. I'm not even sure how closely Braket promises to follow the openQASM specification, so perhaps it's a non-issue.
To reproduce
from braket.circuits import Circuit
from braket.devices import LocalSimulator
device = LocalSimulator()
quantum_circuit = Circuit.from_ir('''
OPENQASM 3.0;
include "stdgates.inc";
qubit[1] q;
ry(1/2) q;
''')
quantum_circuit.probability()
res = device.run(quantum_circuit, 0)
print(res.result().values)
Expected behavior
The ry(1/2) should resolve to ry(0) here resulting in a 1.0 probability of q being 0. To use floating point division it would need to be 1.0 / 2, 1 / 2.0 or 1.0 / 2.0.
Screenshots or logs
Actual output: [array([0.93879128, 0.06120872])]
System information
A description of your system. Please provide:
Describe the bug After some discussion here: https://github.com/Qiskit/qiskit/issues/12167, it seems that the
stdgates.inc
definitiongate sx a { pow(1/2) @ x a; }
should have the1/2
resolve to0
thanks to integer division (i.e.stdgates.inc
has an incorrect definition ofsx
gate). As it stands, it seems that when interpreting openQASM 3, the Braket sim treats these values as floats (which makes thatsx
gate definition behave correctly). Apparently the relevant part of the specification is here: https://openqasm.com/language/classical.html#integers.Being as 'fixing' this would break
stdgates.inc
as of right now, I don't think it should be 'fixed' yet. I'm not even sure how closely Braket promises to follow the openQASM specification, so perhaps it's a non-issue.To reproduce
Expected behavior The
ry(1/2)
should resolve tory(0)
here resulting in a 1.0 probability of q being 0. To use floating point division it would need to be1.0 / 2
,1 / 2.0
or1.0 / 2.0
.Screenshots or logs Actual output:
[array([0.93879128, 0.06120872])]
System information A description of your system. Please provide:
Additional context N/A