Error when FreeParameters are named QASM types

[mbeach-aws]

Describe the bug
When a user defined a FreeParameter("str") where the "str" is a OpenQASM keyword. For example, it fails for b, q, bit, qubit, input, OPENQASM, 3.0. 1,2.
To reproduce

from braket.circuits import Circuit, FreeParameter
from braket.devices import LocalSimulator

b = FreeParameter("b")

circ = Circuit().rx(0,b)
print(circ)

device = LocalSimulator()

task = device.run(circ, shots=1_000, inputs={"b": 0})
task.result().measurement_counts

gives the error

    221     return builtin_constants[node.name]
    222 if not self.context.is_initialized(node.name):
--> 223     raise NameError(f"Identifier '{node.name}' is not initialized.")
    224 return self.context.get_value_by_identifier(node)

NameError: Identifier 'b' is not initialized.

Expected behavior
Expected the circuit to run correctly. For example, using FreeParameter("a") works correctly.

[ajberdy]

For context, here is the OpenQASM generated when an input is named b

OPENQASM 3.0;
input float b;
bit[1] b;
qubit[1] q;
rx(b) q[0];
b[0] = measure q[0];

[guomanmin]

b and q are used as variable names by the Braket SDK and will cause a collision if customers create parameters with the same names. To mitigate this, we will update these automatically created variables to __bits__ and __qubits__.

The other variable names listed conflict with OpenQASM naming standards and we will update documentation to reflect this.

[rmshaffer]

Reopening this issue, as PR #675 was reverted by PR #701. Additionally, I think there is still a need to document the fact that OpenQASM language-reserved words (such as input, angle, etc.) are not allowed as FreeParameter names. Ideally this would give an error message but at the very least it should be documented (e.g. in the FreeParameter documentation).

[laurencap]

I don't see on #701 the reason for reverting. Anyone know what the issue was?

[rmshaffer]

I don't see on #701 the reason for reverting. Anyone know what the issue was?

I believe there was an issue with a particular OpenQASM parser not properly handling variable names beginning with __, which essentially caused it to be a breaking change when using that parser.

[mbeach-aws]

Any progress on this issue? @kshitijc

[Tarun-Kumar07]

Hi @rmshaffer and @mbeach-aws , I would like to tackle this issue as part of unitary hack.

[Tarun-Kumar07]

Hi @rmshaffer and @mbeach-aws,

I came up with two solutions, please let me know which I should proceed with.

Solution 1

• We always prefix FreeParameter, e.g., FreeParameter("b") => fp_b.
• If we use this, we can skip the validation of using OpenQASM language-reserved keywords as there would be no collision.
• Here, users will have more flexibility in providing the name.

Solution 2

• As done in #675, we can use different names for q and b:
  • q => sdk_total_qubits
  • b => sdk_total_bits
• Here, we would need to document not to use OpenQASM language-reserved keywords and the above two mentioned variable names to avoid collisions.
• Here, users would have less flexibility in providing the name.