Proposal: Multi-qubit measurements

[antalsz]

Multi-qubit measurements

Summary

This proposal extends Quil's MEASURE instruction to support measuring multiple qubits at once, as in MEASURE 0 ro[0], 1 ro[1], so that it can use a calibration optimized for measuring multiple qubits simultaneously. The proposal as written builds on the "named measurements" proposal, but this is inessential; it's done this way just in order to avoid rewriting text if the named measurements proposal is accepted. None of the semantic details depend on named measurements.

Motivation

Currently, Quil only supports measuring a single qubit at a time. However, quantum engineers can provide an optimized implementation of measurement for multiple qubits at once, so we want to provide a specific physical realization for e.g. MEASURE 0, 1 that would be distinct from the physical realization of MEASURE 0; MEASURE 1.

Proposed change

We propose generalizing the MEASURE instruction to take multiple qubits, allowing the user to write MEASURE 0 ro[0], 1 ro[1]. This would have the same semantics as MEASURE 0 ro[0]; MEASURE 1 ro[1] at the level of the quantum abstract machine, but could be realized via a more efficient calibration. The precise syntax we want for this is unsettled; see the "Unresolved questions" section for a discussion of the options.

Concretely, this involves changing §7 "Measurement" to update the definition of MEASURE and §12.6 "Defining Calibrations" in Annex T to update DEFCAL MEASURE correspondingly.

The precise updated specification text in this proposal assumes that the "named measurements" proposal has been adopted, but this is not essential; semantically speaking, the changes are independent of each other.

The necessary changes to §7 "Measurement" are as follows:

• Changing ⟨Measurement for Effect⟩ and ⟨Measurement for Record⟩ nonterminals to support multiple arguments.

• Updating the operational semantics of these instructions to refer correctly to multiple qubits.

• Clarifying existing wording in the presence of these content changes.

The result is the following new text:

7. Measurement

[…]

Measurement-for-effect measures qubits and discards the results of those measurements.

⟨Measurement for Effect⟩ ::= MEASURE ([ ⟨Identifier⟩ ])? ⟨Formal Qubit⟩ (, ⟨Formal Qubit⟩)*

This measurement will stochastically project each of the specified qubits into either […]

Measurement-for-record is the same as measurement-for-effect, but also returns the resulting states to the Quil program:

⟨Measurement for Record⟩ ::= MEASURE ([ ⟨Identifier⟩ ])? ⟨Formal Qubit⟩ ⟨Memory Reference⟩ (, ⟨Formal Qubit⟩ ⟨Memory Reference⟩)*

Here, the memory references must all be either of type BIT or INTEGER. Regardless of their types, for each pair of a qubit and memory reference, a 0 is deposited at the given memory location if its corresponding qubit was measured to be in the zero-state, and a 1 is deposited there otherwise. […]

Note that there is no way in Quil to measure all qubits simultaneously; the set of qubits to be measured must be given explicitly.

The same changes must be reflected in the DEFCAL MEASURE calibration specified in Annex T. We need to make the following changes to §12.6 "Defining Calibrations":

• Changing the ⟨Measurement Calibration⟩ nonterminal to match MEASURE instructions by supporting multiple arguments.

• Adding text clarifying how measurement calibrations are matched to MEASUREs when there are multiple qubits involved.

The result is the following new text:

12.6. Defining Calibrations

[…]

⟨Measure for Effect Calibration⟩ ::= DEFCAL MEASURE ([ ⟨Identifier⟩ ])? ⟨Formal Qubit⟩ (, ⟨Formal Qubit⟩)* : ⟨Instruction⟩+

⟨Measure for Record Calibration⟩ ::= DEFCAL MEASURE ([ ⟨Identifier⟩ ])? ⟨Formal Qubit⟩ ⟨Identifier⟩ (, ⟨Formal Qubit⟩ ⟨Identifier⟩)* : ⟨Instruction⟩+

⟨Measure Calibration⟩ ::= ⟨Measure for Effect Calibration⟩ | ⟨Measure for Record Calibration⟩

[…] Similarly, calibrations for measurements can be defined by mapping a combination of (optional measurement name, list of qubits and optional identifiers) to a sequence of analog control instructions.

Multiple gate calibration definitions can be defined for different parameter and qubit values. […]

[…]

An analogous but simpler system applies for MEASURE. […] The behavior of matching on qubits is the same as for gate calibrations; the particular identifiers used for measurement-for-record, just like the particular identifiers used for formal qubits, never matter when matching.

It is important to note that measurement calibrations are sensitive to the order the qubits are specified in. While semantically, it does not matter which order measurement happens in, we require qubits to match in-order as is done for gates. To provide symmetry, a calibration may be provided that forwards to the correspond MEASURE with its qubits in the canonical order; for instance, we could defined

DEFCAL MEASURE 1 dest1, 0 dest0:
    MEASURE 0 dest0, 1 dest1

For example, given the following list of calibration definitions in this order:

[…]

5. DEFCAL MEASURE 0 dest0, 1 dest1:

The instruction MEASURE 0 ro[0], 1 ro[1] would match (5), […], and both the instruction MEASURE[midcircuit] 1 and MEASURE 1 ro[1], 0 ro[0] would not match anything.

Examples:

[…]

# Multi-qubit measurement
DEFCAL MEASURE 0 dest0, 1 dest1:
    DECLARE iq0 REAL[2]
    DECLARE iq1 REAL[2]
    CAPTURE 0 "out0" flat(1e-6, 1+2i) iq0 # different waveform than either of the above
    CAPTURE 1 "out1" flat(1e-6, 3+4i) iq1
    LT dest0 iq0[0] 0.5 # thresholding
    LT dest1 iq1[0] 0.5 # thresholding

Unresolved questions

Syntax

The precise syntax specified above is not set in stone. The ideal syntax would probably be

MEASURE 0 1 ro[0] ro[1]

but unfortunately this suffers from a fatal ambiguity: as the qubits provided to MEASURE can be formal qubits, they would be ambiguous with bare memory identifiers, so that MEASURE x y could be understood as either (1) a 2-qubit measure-for-effect of formal qubits x and y, or (2) a 1-qubit measure-for-record of formal qubit x into the memory location y[0].

Consequently, we need to provide some more imaginative syntax, but we are further constrained by not breaking backwards compatibility. We could, for instance, imagine writing

MEASURE 0 1 -> ro[0] ro[1]

but this implies that we would need to write MEASURE 0 -> ro, which would break all old programs. We could work around this by coupling this multi-qubit–aware syntax with named measurements and introducing both at the same time, so that you could write

MEASURE 0
MEASURE 0 ro
MEASURE[midcircuit] 0
MEASURE[midcircuit] 0 -> ro
MEASURE[midcircuit] 0 1
MEASURE[midcircuit] 0 1 -> ro[0] ro[1]

but you could never write MEASURE 0 1. Then all existing Quil code would continue to work, as it would not be using named measurements; however, named measurements and bare measurements would be frustratingly asymmetric.

Thus, as far as I can see there are two options:

• We require a sigil of some sort to denote multi-qubit measurement, and use a separator such as the arrow. For instance, to introduce a multi-qubit measurement, you could be required to include a leading colon:

  MEASURE: 0 1 -> ro[0] ro[1]
  MEASURE: 0 1
  # Degenerate case, but would work fine
  MEASURE: 0 -> ro
  MEASURE: 0
  # Old style
  MEASURE 0 ro
  MEASURE 0
  

  This would then leave the sigil-less form as old convenience syntax for the single-qubit case. This works but is a very aggressive change that leaves the resulting syntax looking irregular.

• Some form of syntax that introduces a separator after the first qubit-and-optional-identifier, like the comma-separated one presented above. Commas certainly aren't the only options; there's also MEASURE 0 ro[0] & 1 ro[1] or any one of a number of different characters.

I'm open to suggestions here, or to somebody being clever about the syntax and coming up with something yet better.

Measuring every qubit

We could say that a bare MEASURE now measures every qubit, simply by replacing the final sentence of §7 with

A measure-for-effect with no qubits specified measures every qubit. Note that there is no way in Quil to measure-for-record all qubits simultaneously. (Where would you put the results?)

and updating the corresponding grammar productions. It is unclear precisely how to specify the corresponding DEFCAL MEASURE, but this could be resolved. I suspect there is no reason to make this change – and perhaps a reason it was originally forbidden – but it also would not be difficult to do.

Qubit ordering

As specified above, we require that MEASUREs match DEFCAL MEASUREs whose qubits are in the same order, and proposed specifying calibrations for MEASURE 1, 0 that simply forward to MEASURE 0, 1. While this works for the 2-qubit case, it gets much worse much faster for the n-qubit case; we don't want to have to specify all n! permutations. We could resolve this by saying that DEFCAL MEASUREs are unordered, and qubit matching is done on the set of provided qubits. This is odd in the presence of formal qubits, but works fine; if you have MEASURE 0, 1, 2, 3 and the two calibrations DEFCAL MEASURE 0, 1, x, y and DEFCAL MEASURE 2, 3, z, w, you simply pick the one specified last, as you do for gates. It's worth noting that it would be almost backwards-compatible to initially require precise ordering matching and then later relax this to unordered matching if this is a problem; it would simply require deleting the forwarding calibrations.

Repeated qubits

Nothing prevents the user from writing MEASURE 0 ro[0], 0 ro[1]. It's not clear that this is actually a problem. Presumably there either wouldn't be a corresponding calibration, or if there is it would be because it has a specific meaning. But we could also choose to forbid repeated qubits in a single MEASURE if we want. It does get more challenging to specify in the unordered-qubit case, but we could say that the order of the same qubits is preserved.

Measuring into a vector

The design proposed above requires specifying separate memory locations for every qubit in a measure-for-record. We could imagine instead specifying the behavior of multi-qubit measure to read into a vector, so that MEASURE 0, 1, 2 INTO ro would measure qubit 0 into ro[0], qubit 1 into ro[1], and qubit 2 into ro[2]. This is subject to the same questions of syntax as before, as well as questions of semantics: If ro is too long, does this just read into a prefix? Is there a way to read into ro starting at a different index (say, MEASURE 0, 1, 2 INTO ro FROM 3)? Should this coexist with the per-qubit memory locations described above as simply a (possibly more efficient) shorthand, or should it be the only way to perform measurement? It's also not clear if this is compatible with unordered measurement calibrations, as there are then two possible orders (the MEASURE order and the DEFCAL order).

Alternative designs

While we want to provide the ability to use these optimized multi-qubit measurement calibrations, we could avoid the need to provide a multi-qubit measurement instruction by specifying that consecutive measures with the same name are coalesced: if the user writes

MEASURE 0
MEASURE 1

then we first look for a DEFCAL MEASURE 0, 1 calibration before looking for two separate DEFCAL MEASURE 0 and DEFCAL MEASURE 1 calibrations. If the user wants to prevent this coalescing, they can insert a NOP between successive MEASUREs.

This design also works, but requires carefully specifying the calibration matching behavior. Suppose we have the instructions

MEASURE 0
MEASURE 1
MEASURE 2
MEASURE 3
MEASURE 4

in the presence of the following calibrations:

DEFCAL MEASURE 0: …
DEFCAL MEASURE 1: …
DEFCAL MEASURE 2: …
DEFCAL MEASURE 3: …
DEFCAL MEASURE 4: …

DEFCAL MEASURE 0, 1: …
DEFCAL MEASURE 2, 3, 4: …
DEFCAL MEASURE 3, 4: …

How should this be matched? There are a few possibilities:

• Without a specific DEFCAL MEASURE 0, 1, 2, 3, 4, this should simply match the 5 individual DEFCAL MEASURE qs.

• Greedily match the last possible calibration, so that we match DEFCAL MEASURE 3, 4, DEFCAL MEASURE 2, and DEFCAL MEASURE 0, 1.

• Match the longest possible calibration, so that we match DEFCAL MEASURE 0, 1 and DEFCAL MEASURE 2, 3, 4.

Any of these is liable to become confusing, and requires Quil to do more analysis than it has had to previously. The simpler behavior of allowing the user to write multi-qubit MEASURE directly is probably preferable.

Issues

There are a number of unanswered questions, and we want to make sure we pick the right design: one that provides the people interacting with the hardware the power they need, that's easy to use for Quil programmers, and that's possible to implement for people writing Quil tooling. This will require careful thought and coordination with all of the aforementioned groups.

This change requires extending all implementations of Quil, including both quil-rs and Quilc. This is not prohibitive, but is work that would need to be done. I would be happy to make the necessary changes to both the aforementioned projects.

[antalsz]

This is the third of three proposals related to measurement in Quil; see also #90 and #91.

[mhodson-rigetti]

Here's an idea which might remove the need for the comma separator, and addresses the requirement that you enumerate each individual storage BIT location even if they are a single memory register. I'm not sure if it helps resolve the identified MEASURE grammar issue.

Chained arrays (a.k.a. rope-like or segmented arrays)

What if you made the single final operand of a record-type measurement a chained array? This would look like:

DECLARE ro BIT[3]
MEASURE 0 1 2 ro

Which is the same as explicitly chaining (arbitrary choice: pipe operator) the three memory locations together:

DECLARE ro BIT[3]
MEASURE 0 1 2 ro[0]|ro[1]|ro[2]

But can just as easily come from chaining discontinuous memory locations:

DECLARE x BIT
DECLARE y BIT
DECLARE z BIT
MEASURE 0 1 2 x|y|z

The DEFCAL set up is not very different to what you had:

DEFCAL MEASURE 0 1 dest:
    DECLARE iq0 REAL[2]
    DECLARE iq1 REAL[2]
    CAPTURE 0 "out0" flat(1e-6, 1+2i) iq0 # different waveform than either of the above
    CAPTURE 1 "out1" flat(1e-6, 3+4i) iq1
    LT dest[0] iq0[0] 0.5 # thresholding
    LT dest[1] iq1[0] 0.5 # thresholding

Could that resolve the grammar issue?

[antalsz]

I think that still has the same syntactic ambiguity issues, unfortunately; MEASURE x y z ro could either be a measurement-for-effect of the 4 qubits x, y, z, and ro, or it could be a measurement-for-record of the three qubits x, y, and z into ro[0,1,2].

[kalzoo]

No strong preference on the syntax; I am less bothered about things like this:

This works but is a very aggressive change that leaves the resulting syntax looking irregular.

---

Measuring every qubit

I don't see value in supporting this, and I agree it's awkward

Qubit ordering

I prefer the simplicity of ordered qubits in the calibration to make matching simpler; AFAICT it does not remove anything from user control, it just requires them to mind the ordering in the invocation.

Repeated qubits

agreed with you that this is simple to support if the qubit arguments are ordered

Measuring into a vector

Also favoring simplicity, I like the explicit nature of specifying each offset in the invocation. The compiler has to do that anyway, so why force the user to write to a contiguous array, even with an offset? Extra complexity for no value except a few characters saved.

[mhodson-rigetti]

Also favoring simplicity, I like the explicit nature of specifying each offset in the invocation. The compiler has to do that anyway, so why force the user to write to a contiguous array, even with an offset? Extra complexity for no value except a few characters saved.

I don't; as a user I would want to measure multiple qubits into an array readout register in a single reference. "The compiler has to do that anyway" sounds like an argument to make the compiler writer's life easier, not the user's, and I don't think that's the aim of the spec.

[antalsz]

I think we could provide both behaviors, and maybe solve the syntax problem, with the following approach:

1. The primitive form, and the only form used by DEFCAL MEASURE, is the comma-separated form: MEASURE 0 x, 1 y, 2 z.

2. Additionally, we provide another form for reading into an array: MEASURE 0 1 2 -> ro (assuming DECLARE ro BIT[3]). This is precisely sugar for MEASURE 0 ro[0], 1 ro[1], 2 ro[2]. Calling it "precisely sugar" also answers the question "can ro be larger than 3?" (yes, it can).

The nice thing about this is that because the convenience form is just sugar, we don't need to figure out how to handle edge cases with it; if you want something more complex, or if you want a multi-qubit measure-for-effect, just write the comma-separated form. But @mhodson-rigetti is right that in practice, many if not most usages will be MEASURE 0 1 2 3 -> ro. And that form can have the more natural syntax at the cost of a separator. It happens that MEASURE 0 -> ro and MEASURE 0 ro are two ways of writing the same thing, but now that falls out naturally!

The only risk to this I see is that it's so ergonomic that users might try to write MEASURE 0 1 2 -> ro even if there's no DEFCAL MEASURE 0 dest0, 1 dest1, 2 dest2: and then this would fail on the Quil-T side of things. We could solve that by providing calibrations that fall back to the single-qubit calibrations. In either case, this wouldn't affect the QVM level of things at all.

I went with -> because that's my preferred syntax and I think it reads more clearly, but it's possible that to fit with Quil we should use a keyword instead. In that case I'd go with MEASURE 0 1 2 INTO ro, but that does require us to reserve the keyword INTO.

This is now my favored approach, and I'll probably try to update the proposal with it in the next couple of days.

[mhodson-rigetti]

We could solve that by providing calibrations that fall back to the single-qubit calibrations.

Just confirming this can be achieved with only linear complexity, not combinatorial, up to the maximum physical system size, by parameterizing all of the larger DEFCAL MEASURE declarations?

DEFCAL MEASURE q0 dest0, q1 dest1:
    MEASURE q0 dest0
    MEASURE q1 dest0

DEFCAL MEASURE q0 dest0, q1 dest1, q2 dest2:
    MEASURE q0 dest0
    MEASURE q1 dest0
    MEASURE q2 dest0

...

This makes me think of something I didn't notice before; when joined with #90 will it be supported that the context identifier is a parameter that can be passed through? For example...

DEFCAL MEASURE[any_context] q0 dest0, q1 dest1:
    MEASURE[any_context] q0 dest0
    MEASURE[any_context] q1 dest0

DEFCAL MEASURE[any_context] q0 dest0, q1 dest1, q2 dest2:
    MEASURE[any_context] q0 dest0
    MEASURE[any_context] q1 dest0
    MEASURE[any_context] q2 dest0

...

... and would you need both forms explicitly declared in Quil-T in order to resolve both, or does the context-less form match to the context-aware form with some sort of null context that has the same effect?

[antalsz]

@mhodson-rigetti

Just confirming this can be achieved with only linear complexity

That's an excellent question. I hadn't actually realized that it could, but yes – what you proposed would be the only plausible reading of the semantics I provided.

will it be supported that the context identifier is a parameter that can be passed through?

That is not provided by this proposal or by #90, and I'd like to leave that out of scope until we run into that being necessary in practice; I'm not sure what the right syntax would be.

or does the context-less form match to the context-aware form with some sort of null context that has the same effect?

It definitely doesn't; this is outlined in the examples in #90, where MEASURE[midcircuit] 1 doesn't match DEFCAL MEASURE qubit:. And this is deliberate; if, for instance, MEASURE is end-of-circuit measure, we don't want silent fallback from midcircuit measurement to end-of-circuit measurement just because we were missing a calibration.

---

I'd like to propose that for now, we stick with providing the most basic form:

• Explicit, ordered multi-qubit MEASURE calibrations.
• No implicit fallback unless you write the DEFCAL MEASURE q0 dest0, q1 dest1, …: yourself.
• If we provide the read-into-an-array sugar, provide it only in the simplest case where MEASURE 0 1 2 -> ro is exactly equivalent to MEASURE 0 ro[0], 1 ro[1], 2 ro[2], and don't provide any other extensions to it.

There are a lot of possible ways to generalize and extend this feature, and some of them conflict with each other; I'd like to leave them undefined until we know which behaviors we actually want. For instance, suppose we have efficient calibrations for measuring qubits 0, 1, 2 and qubits 3, 4, 5, but then we write MEASURE 0 1 2 3 4 5 -> ro and it falls back to six individual measurements. Is that expected? Unexpected? A problem? Let's see how this is used before deciding.

[mhodson-rigetti]

or does the context-less form match to the context-aware form with some sort of null context that has the same effect?

It definitely doesn't

Agreed and satisfied.

[Shadow53]

I'd like to propose that for now, we stick with providing the most basic form:

• Explicit, ordered multi-qubit MEASURE calibrations.
• No implicit fallback unless you write the DEFCAL MEASURE q0 dest0, q1 dest1, …: yourself.
• If we provide the read-into-an-array sugar, provide it only in the simplest case where MEASURE 0 1 2 -> ro is exactly equivalent to MEASURE 0 ro[0], 1 ro[1], 2 ro[2], and don't provide any other extensions to it.

This seems like a reasonable starting point. That is, I think it makes sense to extend the syntax of MEASURE from (using regex-like notation):

MEASURE <qubit> <memory_reference>

To this:

MEASURE( <qubit> <memory_reference>)+

I don't think commas are necessary in this case, as it's guaranteed that every odd argument is a qubit and every even argument is a destination. Though perhaps commas -- or some other punctuation -- would be useful as a separator if many qubits are measured at once.

Also note the requirement that at least one pair is provided. I think that gives us a better starting point to work from and allows us to support a bare MEASURE in the future if necessary,

---

Regarding the sugar for reading multiple qubits into an array, we should consider the semantics of whether it represents assignment or appending:

DECLARE ro BIT[9]
MEASURE 0 1 2 -> ro  # ro = [q0, q1, q2, ...]
MEASURE 3 4 5 -> ro  # ro = [q3, q4, q5, ...] or [q0, q1, q2, q3, ...] ?

A way to be unambiguous about this, provide a sugared syntax for assigning multiple contiguous indices in an array, and even support mid-array assignment would be requiring something akin to Python's slicing syntax:

DECLARE ro BIT[9]
MEASURE 0 1 2 -> ro[:3]  # [start, end) with implied start = 0 and end = len-1
MEASURE 3 4 5 -> ro[3:6]
MEASURE 6 7 8 -> ro[6:]

For assigning the entirety of an array at once, both sides could be omitted:

DECLARE ro BIT[3]
MEASURE 0 1 2 -> ro[:]

Which brings us back around to a possible syntax omitting the [], but with a very narrow meaning: assign the entirety of the array:

DECLARE ro_good BIT[3]
DECLARE ro_bad BIT[4]
MEASURE 0 1 2 -> ro_good # same length as array
MEASURE 3 4 5 -> ro_bad  # ERROR: not same length as array

---

Regarding repeated qubits, I see another potential ambiguity. Should MEASURE 0 ro[0] 0 ro[1] expand like this:

# Measure twice
MEASURE 0 ro[0]
MEASURE 0 ro[1]

Or like this?

# Read once and assign multiple times
MEASURE 0 ro[0]
MOVE ro[1] ro[0]

Similarly, what if the same qubit/memory pair is provided multiple times? E.g., MEASURE 0 ro[0] 0 ro[0]?

[antalsz]

@Shadow53: Thanks for the input!

I don't think commas are necessary in this case, as it's guaranteed that every odd argument is a qubit and every even argument is a destination.

This is only true if we limit our support to multi-qubit measurement-for-record; otherwise, MEASURE x y z w is either "measure the formal qubit x into the memory location y and the formal qubit z into the memory location w" or "measure the formal qubits x, y, z, and w, discarding the results".

Regarding the sugar for reading multiple qubits into an array, we should consider the semantics of whether it represents assignment or appending

Appending doesn't make sense in a language like Quil with only fixed-size arrays. Quil arrays don't have a notion of "current element" or "initialized prefix" and they can't be resized, so there's no way to implement "append". (You could try something like scanning the code to see if there are repeated MEASUREs into the same region and then treating each successive MEASURE differently, but that fails in the presence of control flow or other operations that assign to the same region.)

A way to be unambiguous about this, provide a sugared syntax for assigning multiple contiguous indices in an array, and even support mid-array assignment would be requiring something akin to Python's slicing syntax:

I specifically wanted to rule out extensions like that when proposing that "the most basic form" we start with should allow this sugar "only in the simplest case", even though I agree such extensions would likely be useful eventually. I could be argued around to including them in the minimal proposal, but my starting point is that I don't think they need to be part of the first version.

[have MEASURE x y -> ro] assign the entirety of the array [i.e., require matching lengths]

We could do this instead of "assign into the leading prefix"; it's certainly backwards-compatible to start that way. There's no way to express that check with existing Quil, but it's an entirely static check so it probably doesn't show up as new capabilities we'd want to expose elsewhere.

Should MEASURE 0 ro[0] 0 ro[1] expand like this:

# Measure twice
MEASURE 0 ro[0]
MEASURE 0 ro[1]

Or like this?

# Read once and assign multiple times
MEASURE 0 ro[0]
MOVE ro[1] ro[0]

It doesn't matter! At the level of the quantum abstract machine, those have precisely the same runtime effect. At the level of Quil-T, the answer is "neither, it looks up the DEFCAL MEASURE 0 dest_a 0 dest_b calibration". The spec text as written is intended to describe the operational semantics as the former, which tells the Quil-T calibration author which form they should implement – and this could be clarified – but on the abstract machine there are no fidelity issues so the two are the same. (I actually suspect Quil-T calibrators simply won't provide such calibrations, making the issue entirely moot.) Also note that the spec text as written doesn't expand the multi-qubit measures at the Quil level at all; there's no DEFMULTIMEASURE that could do the expansion. It's only at the level of Quil-T's DEFCAL MEASURE than expansion happens at all.

Similarly, what if the same qubit/memory pair is provided multiple times?

Thanks for catching this! In the particular case where the qubits are the same, it again doesn't matter on the abstract machine, but the more general question of "what if the same memory location is provided multiple times" needs to be addressed for both the abstract machine and the Quil-T realization. I would suggest one of two additions to the text of §7: either

If the same memory location is measured into multiple times, the final (rightmost) qubit measured into it determines the final value deposited at that location.

or

If the same memory location is measured into multiple times, the value deposited into it will be determined by measuring one of the corresponding qubits, but which qubit's value winds up there is not specified.

The first is probably better, I don't think we need the freedom the latter gives us. (Because memory can be indexed with variables, we can't simply statically forbid writing code like this; the user might write MEASURE 0 ro[i], 1 ro[j] and then we can't know ahead of time if they alias.)

Edit: Actually, I take that back – due to the quantum abstract machine and real quantum computers operating multiple qubits concurrently, I think we do want the flexibility of the latter text! I'd like to believe we can at least say some legal value gets written there, though, rather than having to make it totally indeterminate.

[bramathon]

I also prefer this syntax:

DECLARE ro BIT[3]
MEASURE 0 1 2 ro

but I would naturally expect it to look more like:

DECLARE ro BIT[3]
MEASURE 0 1 2 ro[0:3]

or

DECLARE ro BIT[3]
MEASURE 0 2 ro[(0 2)]