Allow float/angle interaction in gate-parameter contexts #35
Conversation
This allows technically invalid OpenQASM 3, but is in practice what Qiskit's OpenQASM 3 exporter outputs due to problems in how it represents symbolic expressions. It's probably better for users to allow the technically invalid OpenQASM 3 than to punish them for things that are actually Qiskit's fault.
This is the same as the multiplication/division part. While it's much less likely for these to appear from the Qiskit export, it makes sense to allow them in non-strict mode for symmetry.
| @@ -233,6 +241,13 @@ def visit_BinaryExpression(self, node: ast.BinaryExpression): | |||
| elif isinstance(rhs_type, types.Angle): | |||
| const = lhs_type.const and rhs_type.const | |||
| out_type = types.Uint(const, None) | |||
| # We allow `angle / float` in non-strict mode, because the Qiskit OQ3 exporter does | |||
| # not / cannot handle `ParameterExpression` well on output, and often outputs things | |||
| # like that. That's invalid OQ3, but it's better to support Qiskit's dodgy output | |||
There was a problem hiding this comment.
Is there an issue tracking this in the language specification? Or was this already discussed and decided that this should not be allowed. It seems odd to me though if this was the decision since it seems pretty natural to perform arithmetic operations between an angle and a float.
There was a problem hiding this comment.
An angle is an integer-like representation as fractions of float doesn't interact with angle. That said, there's still awkwardnesses in the whole model around the angle type being naturally defined on a ring.
This allows technically invalid OpenQASM 3, but is in practice what Qiskit's OpenQASM 3 exporter outputs due to problems in how it represents symbolic expressions. It's probably better for users to allow the technically invalid OpenQASM 3 than to punish them for things that are actually Qiskit's fault.
Fix #25.