RFC: refactoring measurement

[Roger-luo]

The Measure statement is not very compatible with stim or QASM2

from stim there are

• PPMeasure(p: float, pauli_string) -> bool: measure on a Pauli string as basis by a given probability
  • measure XXYY on 4 qubits resulting a boolean value
  • p is the probablity of -> bool being flipped
  • MZZ, etc.
• Measure(basis, position, p: float) -> bool

from QASM2 there are

• Measure(qreg, creg)

We introduce the following statement to model all the above

# in wire
class Measure:
    basis: ir.SSAValue = info.argument(OpType)
    wires: tuple[ir.SSAValue, ...] = info.argument(Wire)
    prob: ir.SSAValue = info.argument(Union[Float, NoneType])

# in qubit
class Measure:
    basis: ir.SSAValue = info.argument(OpType)
    qubits: ir.SSAValue = info.argument(IListType[Qubit, ...])
    prob: ir.SSAValue = info.argument(Union[Float, NoneType])

parallel {
    %1 = Measure(basis, (%wire_1, %wire_2), p=None) -> bool
    %2 = Measure(basis, (%wire_3, %wire_4), p=None) -> bool
}

cc: @kaihsin @johnzl-777

[cduck]

Is prop the probability of a measurement error? I'm not sure it should be included in a general Measure instruction. If you need to represent errors for simulation, simply do Depolarizing(wires, px=prob, py=0, pz=0); Measure('Z', wires).

[kaihsin]

How about PPMeasure? This issue also try to unify them together

[Roger-luo]

Is prop the probability of a measurement error?

yes, the prob is the error of measurement output being flipped.

I'm not sure it should be included in a general Measure instruction. If you need to represent errors for simulation, simply do Depolarizing(wires, px=prob, py=0, pz=0); Measure('Z', wires).

I think this makes sense to me, this is due to a noise channel. I'm actually wondering what are the corresponding noise operator for a PPMeasure here?

[cduck]

Neutral atoms don't directly measure Pauli products so there is no direct noise model. You have to decompose it into a circuit with an additional ancilla. Measuring the Pauli string X1Y2Z3:

The noise depends on how you execute this circuit so I don't think including a "probability" argument at this IR level makes any sense.

[kaihsin]

I guess this should an optimization pass on the Stim level?

…

On Tue, Apr 15, 2025, 14:52 Casey Duckering ***@***.***> wrote: Neutral atoms don't directly measure Pauli products so there is no direct noise model. You have to decompose it into a circuit with an additional ancilla. Measuring the Pauli string X1Y2Z3: Screenshot.2025-04-15.at.14.50.44.png (view on web) <https://github.com/user-attachments/assets/71fe5432-592f-4d3e-b1d3-efb8de5d185f> The noise depends on how you execute this circuit so I don't think including a "probability" argument at this IR level makes any sense. — Reply to this email directly, view it on GitHub <#158 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFCX3SKUCMQIFV6FVZS5VZ32ZVIOXAVCNFSM6AAAAAB3GKYBD6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMBXGE3TGOJYGE> . You are receiving this because you were mentioned.Message ID: ***@***.***> *cduck* left a comment (QuEraComputing/bloqade-circuit#158) <#158 (comment)> Neutral atoms don't directly measure Pauli products so there is no direct noise model. You have to decompose it into a circuit with an additional ancilla. Measuring the Pauli string X1Y2Z3: Screenshot.2025-04-15.at.14.50.44.png (view on web) <https://github.com/user-attachments/assets/71fe5432-592f-4d3e-b1d3-efb8de5d185f> The noise depends on how you execute this circuit so I don't think including a "probability" argument at this IR level makes any sense. — Reply to this email directly, view it on GitHub <#158 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFCX3SKUCMQIFV6FVZS5VZ32ZVIOXAVCNFSM6AAAAAB3GKYBD6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMBXGE3TGOJYGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[cduck]

I don't think we have much use for a squin.PPMeasure instruction so is it OK for squin to not 1-to-1 map to stim? And noise can be a separate noise_op dialect that is compatible with squin and can be added by a noise estimation pass.

[kaihsin]

I see. So your suggestion is to remove probability (noisy measurement) completely at squin level Measurement

…

On Tue, Apr 15, 2025, 15:13 Casey Duckering ***@***.***> wrote: I don't think we have much use for a squin.PPMeasure instruction so is it OK for squin to not 1-to-1 map to stim? And noise can be a separate noise_op dialect that is compatible with squin and can be added by a noise estimation pass. — Reply to this email directly, view it on GitHub <#158 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFCX3SMXCEOROZWJYWFDRMD2ZVK4VAVCNFSM6AAAAAB3GKYBD6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMBXGIZDOOJSGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***> *cduck* left a comment (QuEraComputing/bloqade-circuit#158) <#158 (comment)> I don't think we have much use for a squin.PPMeasure instruction so is it OK for squin to not 1-to-1 map to stim? And noise can be a separate noise_op dialect that is compatible with squin and can be added by a noise estimation pass. — Reply to this email directly, view it on GitHub <#158 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFCX3SMXCEOROZWJYWFDRMD2ZVK4VAVCNFSM6AAAAAB3GKYBD6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMBXGIZDOOJSGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[weinbe58]

I agree that we should decouple the noise from the measurement. Even semantically, it seems redundant.

[zphy]

Agreed with Casey's comment above - physically, noise should be separate, and we don't have native multi-body measurements. In QEC research, the main place we make use of the MPP command is when defining a logical observable, consisting of the product of physical Pauli operators on a bunch of sites, but this can be done in post-processing as well so is not a required functionality.

[kaihsin]

Sounds like a 4 yeses! Let's do it.

[johnzl-777]

Okay so just to make concrete what I understand here and what should be implemented:

• There's no need for something like MPP at the squin level
• Noise shouldn't be "tied in" with measurement statements at all and can be inserted via another pass + represented with a different noise_op dialect

Thus, with some minor modification the new Measure statements (piggybacking off of @Roger-luo 's initial proposal) are now just:

# in wire
class Measure:
    basis: ir.SSAValue = info.argument(OpType)
    wires: tuple[ir.SSAValue, ...] = info.argument(Wire)

# in qubit
class Measure:
    basis: ir.SSAValue = info.argument(OpType)
    qubits: ir.SSAValue = info.argument(IListType[Qubit, ...])

Now one thing I would want to make clear here is in the following:

parallel {
    %1 = Measure(basis, (%wire_1, %wire_2), p=None) -> bool
    %2 = Measure(basis, (%wire_3, %wire_4), p=None) -> bool
}

I assume the bool here would be a proper ir.ResultValue? Although this would still run into the problems discussed in #148

[Roger-luo]

you missed the return value of measure in the its definition. I think the return value should be list of bool, not bool. For parallel

%3, %4 = parallel {
  %1 = measure(%basis, %wire_1, %wire_2) -> IList[bool]
  %2 = measure(%basis, %wire_1, %wire_2) -> IList[bool]
  yield %1, %2
}

[weinbe58]

I thought we were going to remove parallel? If you have measurements that can happen in parallel just merge the arguments?

[Roger-luo]

I thought we were going to remove parallel? If you have measurements that can happen in parallel just merge the arguments?

that's right. We are adding a broadcast/repeat in the operator language.

[johnzl-777]

From a meeting with myself, @david-pl , @Roger-luo , and @weinbe58 the syntax for Measure should be the following.

@overload
def measure(op, q: Qubit) -> bool:
    pass

measure(op, q[0])

@overload
def measure(op, args: IList[Qubit]) -> list[bool]:
    pass

@weinbe58 has asked me to prioritize working on #179 and the (immediately) necessary sub-issues so I'll hand the reigns over to him on this issue 👍

[johnzl-777]

Also want to point out that as of now, Measure as well as MeasureAndReset in the wire dialect have integer types for their results. Updating #180 to align with developments here.