Classical Control: Classical Data Registers #3231

balopat · 2020-08-19T04:06:30Z

Problem:
When running on hardware Cirq supports two uses of classical data. The first is in the supplying of classical information to a circuit as a parameter. The second is as the measurement outcomes recorded in the measurement dictionary. This is not sufficient for future needs (see Feedforward #3232 and Flow Control #3234). Further the output of running a Cirq circuit, measurement dictionaries, is overly restrictive and more general measurement results (IQ points, for example) should be supported. Cirq also lacks the ability to specify classical data which can be loaded by a user, used during running of a circuit, and read out at the end of the circuit. This feature is to add the ability to support classical data.

Rough requirements:

Allow classical data of different types and sizes.
Allow this data to be populated by hardware during measurement or execution of a circuit.
Allow the data to be used to control in the future execution of a circuit
Allow the data to be specified at runtime before a circuit executes.
Allow the data to be read out and returned after the execution of the circuit, extending the measurement dictionary concept
Support only data that can be serialized
Support serialization of the specification of the classical data itself

smitsanghavi · 2020-12-16T20:50:44Z

Should this be added to the 2021 roadmap given that it's the precondition for the above 3 linked issues?

95-martin-orion · 2021-03-03T15:57:23Z

After further consideration, I don't think these concerns are relevant to Cirq outside of the built-in simulators:

Allow [classical] data to be populated by hardware during measurement or execution of a circuit.
Allow [classical] data to be used to control in the future execution of a circuit

Cirq constructs only really matter during translation from and to the Cirq format; any handling of measurement results during circuit execution is the sole responsibility of the device / simulator.

@95-martin-orion

Adds a `ClassicalDataStore` class so we can keep track of which qubits are associated to which measurements. Closes #3232. Initially this was created as part 14 (of 14) of https://tinyurl.com/cirq-feedforward to enable qudits in classical conditions, by storing and using dimensions of the measured qubits when calculating the integer value of each measurement when resolving sympy expressions. However it may have broader applicability. This approach also sets us up to more easily add different types of measurements (#3233, #4274). It will also ease the path to #3002 and #4449., as we can eventually pass this into `Result` rather than the raw `log_of_measurement_results` dictionary. (The return type of `_run` will have to be changed to `Sequence[C;assicalDataStoreReader]`. Related: #887, #3231 (open question @95-martin-orion whether this closes those or not) This PR contains a `ClassicalDataStoreReader` and `ClassicalDataStoreBase` parent "interface" for the `ClassicalDataStore` class as well. This will allow us to swap in different representations that may have different performance characteristics. See #3808 for an example use case. This could be done by adding an optional `ClassicalDataStore` factory method argument to the `SimulatorBase` initializer, or separately to sampler classes. (Note this is an alternative to #4778 for supporting qudits in sympy classical control expressions, as discussed here: https://github.com/quantumlib/Cirq/pull/4778/files#r774816995. The other PR was simpler and less invasive, but a bit hacky. I felt even though bigger, this seemed like the better approach and especially fits better with our future direction, and closed the other one). **Breaking Changes**: 1. The abstract method `SimulatorBase._create_partial_act_on_args` argument `log_of_measurement_results: Dict` has been changed to `classical_data: ClassicalData`. Any third-party simulators that inherit `SimulatorBase` will need to update their implementation accordingly. 2. The abstract base class `ActOnArgs.__init__` argument `log_of_measurement_results: Dict` is now copied before use. For users that depend on the pass-by-reference semantics (this should be rare), they can use the new `classical_data: ClassicalData` argument instead, which is pass-by-reference.

mpharrigan · 2022-03-28T19:51:33Z

@95-martin-orion is this before or after 1.0?

95-martin-orion · 2022-03-28T21:08:01Z

This is functionally complete as of #4781.

@95-martin-orion

…mlib#4781) Adds a `ClassicalDataStore` class so we can keep track of which qubits are associated to which measurements. Closes quantumlib#3232. Initially this was created as part 14 (of 14) of https://tinyurl.com/cirq-feedforward to enable qudits in classical conditions, by storing and using dimensions of the measured qubits when calculating the integer value of each measurement when resolving sympy expressions. However it may have broader applicability. This approach also sets us up to more easily add different types of measurements (quantumlib#3233, quantumlib#4274). It will also ease the path to quantumlib#3002 and quantumlib#4449., as we can eventually pass this into `Result` rather than the raw `log_of_measurement_results` dictionary. (The return type of `_run` will have to be changed to `Sequence[C;assicalDataStoreReader]`. Related: quantumlib#887, quantumlib#3231 (open question @95-martin-orion whether this closes those or not) This PR contains a `ClassicalDataStoreReader` and `ClassicalDataStoreBase` parent "interface" for the `ClassicalDataStore` class as well. This will allow us to swap in different representations that may have different performance characteristics. See quantumlib#3808 for an example use case. This could be done by adding an optional `ClassicalDataStore` factory method argument to the `SimulatorBase` initializer, or separately to sampler classes. (Note this is an alternative to quantumlib#4778 for supporting qudits in sympy classical control expressions, as discussed here: https://github.com/quantumlib/Cirq/pull/4778/files#r774816995. The other PR was simpler and less invasive, but a bit hacky. I felt even though bigger, this seemed like the better approach and especially fits better with our future direction, and closed the other one). **Breaking Changes**: 1. The abstract method `SimulatorBase._create_partial_act_on_args` argument `log_of_measurement_results: Dict` has been changed to `classical_data: ClassicalData`. Any third-party simulators that inherit `SimulatorBase` will need to update their implementation accordingly. 2. The abstract base class `ActOnArgs.__init__` argument `log_of_measurement_results: Dict` is now copied before use. For users that depend on the pass-by-reference semantics (this should be rare), they can use the new `classical_data: ClassicalData` argument instead, which is pass-by-reference.

@95-martin-orion

…mlib#4781) Adds a `ClassicalDataStore` class so we can keep track of which qubits are associated to which measurements. Closes quantumlib#3232. Initially this was created as part 14 (of 14) of https://tinyurl.com/cirq-feedforward to enable qudits in classical conditions, by storing and using dimensions of the measured qubits when calculating the integer value of each measurement when resolving sympy expressions. However it may have broader applicability. This approach also sets us up to more easily add different types of measurements (quantumlib#3233, quantumlib#4274). It will also ease the path to quantumlib#3002 and quantumlib#4449., as we can eventually pass this into `Result` rather than the raw `log_of_measurement_results` dictionary. (The return type of `_run` will have to be changed to `Sequence[C;assicalDataStoreReader]`. Related: quantumlib#887, quantumlib#3231 (open question @95-martin-orion whether this closes those or not) This PR contains a `ClassicalDataStoreReader` and `ClassicalDataStoreBase` parent "interface" for the `ClassicalDataStore` class as well. This will allow us to swap in different representations that may have different performance characteristics. See quantumlib#3808 for an example use case. This could be done by adding an optional `ClassicalDataStore` factory method argument to the `SimulatorBase` initializer, or separately to sampler classes. (Note this is an alternative to quantumlib#4778 for supporting qudits in sympy classical control expressions, as discussed here: https://github.com/quantumlib/Cirq/pull/4778/files#r774816995. The other PR was simpler and less invasive, but a bit hacky. I felt even though bigger, this seemed like the better approach and especially fits better with our future direction, and closed the other one). **Breaking Changes**: 1. The abstract method `SimulatorBase._create_partial_act_on_args` argument `log_of_measurement_results: Dict` has been changed to `classical_data: ClassicalData`. Any third-party simulators that inherit `SimulatorBase` will need to update their implementation accordingly. 2. The abstract base class `ActOnArgs.__init__` argument `log_of_measurement_results: Dict` is now copied before use. For users that depend on the pass-by-reference semantics (this should be rare), they can use the new `classical_data: ClassicalData` argument instead, which is pass-by-reference.

balopat added the kind/roadmap-item for higher level roadmap items to capture conversations and feedback (not for project tracking) label Aug 19, 2020

This was referenced Aug 19, 2020

Classical Control: Feedforward #3232

Closed

Expand measurement results #3233

Closed

Classical Control: Loops/Branches/Conditions #3234

Closed

balopat added the area/classical label Aug 26, 2020

balopat self-assigned this Aug 29, 2020

balopat mentioned this issue Oct 5, 2020

Feature request: classical registers #887

Closed

balopat mentioned this issue Nov 17, 2020

TrialResult should describe which qubits were measured in each measurement key #2412

Open

balopat assigned 95-martin-orion and unassigned balopat Dec 16, 2020

vcatherine changed the title ~~Representing classical data~~ Classical Control: Classical Data Registers Sep 3, 2021

This was referenced Dec 24, 2021

Classical sympy conditions with qudits #4778

Closed

Add ClassicalDataStore class to keep track of qubits measured #4781

Merged

95-martin-orion closed this as completed Mar 28, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Classical Control: Classical Data Registers #3231

Classical Control: Classical Data Registers #3231

balopat commented Aug 19, 2020 •

edited

Loading

smitsanghavi commented Dec 16, 2020

95-martin-orion commented Mar 3, 2021

mpharrigan commented Mar 28, 2022

95-martin-orion commented Mar 28, 2022

Classical Control: Classical Data Registers #3231

Classical Control: Classical Data Registers #3231

Comments

balopat commented Aug 19, 2020 • edited Loading

smitsanghavi commented Dec 16, 2020

95-martin-orion commented Mar 3, 2021

mpharrigan commented Mar 28, 2022

95-martin-orion commented Mar 28, 2022

balopat commented Aug 19, 2020 •

edited

Loading