Preliminary representation of rvalue classical expressions in Terra

[jakelishman]

This is a proposal for initial representation of classical expressions in Terra. It is simple bit-level operations only on effectively Clbit and ClassicalRegister, and is deliberately designed to be separable from the rest of Terra so it can be replaced in the future if necessary, without painful decoupling of these objects from core Terra ones.

This proposal notably does not require any new public methods or trackers on QuantumCircuit, Clbit or ClassicalRegister. This includes not having a way to store a runtime expression in a variable of QuantumCircuit for re-use, nor of using these expressions in the parameters to gates. These may come in the future, but are deliberately excluded from prelim exploratory representations.

[jakelishman]

I just realised that I didn't include QPY support in the RFC, but I think for the MVP use-case we can actually get away without it; the known places that would support these dynamic-circuits paths (i.e. just IBM's qiskit-ibm-provider atm) export to OQ3 on the client side.

[mtreinish]

I just realised that I didn't include QPY support in the RFC, but I think for the MVP use-case we can actually get away without it; the known places that would support these dynamic-circuits paths (i.e. just IBM's qiskit-ibm-provider atm) export to OQ3 on the client side.

Unless something has changed recently it actually does the OQ3 export server-side and submits the circuit as a qpy payload to the ibm runtime environment which calls the op3 export as part of the runner program.

[jakelishman]

I don't think that's the case, because iirc I was able to support switch-statement jobs to the backends back in December directly from Qiskit, without manually exporting to OQ3 myself. But I could be mistaken.

[jakelishman]

Oh no sorry, you're right and I'm totally misremembering. I'll update to add QPY support as a requirement for release.

[kevinhartman]

Looks very cool, overall.

Despite being verbose, I'm a fan of the explicit construction of expressions in Stage 1. Personally, I'm not fully sold on the use of operator overloading in Stage 2. I tend to find it somewhat confusing as a user, since it feels like a surprise when types get magically coerced.

I'm sure you've already considered this, but just in case you haven't, I wonder what you'd think about an expression building syntax that uses chaining.

Here's your example modified to demonstrate what this might look like. Note that this would be in place of using context builders:

from qiskit.circuit import Clbit, ClassicalRegister
from qiskit.circuit.classical import expr

loose = [Clbit() for _ in [None]*3]
cr1 = ClassicalRegister(2)
cr2 = ClassicalRegister(2)

# Equivalent to the current condition `(cr, 2)`:
equal_reg = expr.Value(cr1).eq(2)

# Equivalent to the current condition `(loose[0], False)`
equal_bit = expr.Value(loose[0]).eq(False)

# The above example, but using a Bool-valued unary expression:
not_bit = expr.Value(loose[0]).not()

# The comparison 0 < cr1 <= cr2
bounded_reg = expr.Value(0).lt(cr1).and(expr.Value(cr1).lt_eq(cr2))

Arguments passed to chaining functions could be either of type Expr, or they could be our standard types, which would be coerced into Expr. This is similar to what you propose with operator overloading, but since this only happens for chaining function args, it might give the user better context clues to what is going on (and save an indentation!). Perhaps you could also take advantage of the left-hand side's greater precedence to coerce the right-hand side to match the width in the case of fixed-width type comparisons, though I haven't thought this through.

Assuming you've already considered something like this and have a preference for the proposal as it is, I'm on board with this moving forward as is.

[kevinhartman]

Not fully-qualified in that the size isn't fixed?

[jakelishman]

Yeah, exactly. Yeah, "qualified" doesn't seem like the right word here. I'm pretty sure there is a correct word for it, I just can't think of it.

[jakelishman]

I hadn't actually considered chaining at all - honestly, I hadn't really considered anything much beyond what I wrote because I was rushing to get it up before the meeting yesterday. My rough thoughts on it are:

1. it's definitely acceptable per the goal of "we can tear this out again";
2. it doesn't have the problem that the magic methods have of not being able to override the Python logical operators;
3. I'm not certain it's significantly less verbose than just using all the methods directly, which was the main UX-y goal of the builder interface + overload;
4. I'm not fully sold that expression trees are best represented as chains. I feel like they have a habit of over-promoting the left operand of a binary expression - a.and(b) looks asymmetric, and it's worse when a and b are more complex;
5. (minor) there's a few method names in the chain that wouldn't be allowed - and, not and or would need different names, because they're Python keywords.

On balance, I think I personally still prefer the magic-method arithmetic form, but I'm happy to go with the crowd.

[kevinhartman]

I remember now where I'd originally seen this sort of problem solved. In Apache Spark SQL, they use a sort of DSL for column expressions.

Maybe that can serve as some inspiration for either this RFC or a final design, though I'm sure there are quite a few differences in our requirements.

[kdk]

Looks good so far. Thanks for writing this up.

[kdk]

Thanks for the updates, this LGTM.