SimulatesIntermediateState._base_iterator docstring says it'll be deprecated #5400
Labels
area/simulation
kind/design-issue
A conversation around design
triage/discuss
Needs decision / discussion, bring these up during Cirq Cynque
Comments
dstrain115
added
triage/discuss
|
Discussion from cirq cync: This needs a decision before 1.0 since it affects the user-facing interface, but we were unsure whether it should be done without details from @daxfohl . Keeping it on triage discuss for next time. |
|
I generally have conflicts at that time but I created a simple PR with the implementation details. @95-martin-orion probably has the most context for a go no-go on it. |
CirqBot
pushed a commit
that referenced
this issue
Jun 2, 2022
Fixes #5400 Add a deprecation warning that _base_iterator is going to be made abstract, and copy (with intent to move) the implementation to SimulatorBase. Once the deprecation timeline has passed we can safely make `SimulatesIntermediateState._base_iterator` abstract, and remove `_create_simulation_state`, `_create_act_on_args` and `_core_iterator` declarations from `SimulatesIntermediateState` completely. This makes `SimulatesIntermediateState` more true to its name, as it should not be concerned with how or where the subclass creates the initial state, even from the interface standpoint. @95-martin-orion
rht
pushed a commit
to rht/Cirq
that referenced
this issue
May 1, 2023
Fixes quantumlib#5400 Add a deprecation warning that _base_iterator is going to be made abstract, and copy (with intent to move) the implementation to SimulatorBase. Once the deprecation timeline has passed we can safely make `SimulatesIntermediateState._base_iterator` abstract, and remove `_create_simulation_state`, `_create_act_on_args` and `_core_iterator` declarations from `SimulatesIntermediateState` completely. This makes `SimulatesIntermediateState` more true to its name, as it should not be concerned with how or where the subclass creates the initial state, even from the interface standpoint. @95-martin-orion
harry-phasecraft
pushed a commit
to PhaseCraft/Cirq
that referenced
this issue
Oct 31, 2024
Fixes quantumlib#5400 Add a deprecation warning that _base_iterator is going to be made abstract, and copy (with intent to move) the implementation to SimulatorBase. Once the deprecation timeline has passed we can safely make `SimulatesIntermediateState._base_iterator` abstract, and remove `_create_simulation_state`, `_create_act_on_args` and `_core_iterator` declarations from `SimulatesIntermediateState` completely. This makes `SimulatesIntermediateState` more true to its name, as it should not be concerned with how or where the subclass creates the initial state, even from the interface standpoint. @95-martin-orion
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I looked into actually deprecating this but I don't think deprecation is the right thing to do here.
I believe
SimulatesIntermediateStatehas too much simulation functionality tied to it; it should just be a wrapper around iterating intermediate states. The rest really belongs inSimulatorBase.I think in the final solution,
_base_iteratorshould be an abstract function inSimulatesIntermediateState. The implementation of it should be moved toSimulatorBase. Upon moving that, we can get rid of the abstract functions_create_simulation_state,_create_act_on_args, and_core_iteratorfromSimulatesIntermediateState, since they were only ever used from_base_iteratorimplementation. This provides better separation of concerns, and allows users more flexibility in implementingSimulatesIntermediateState.The text was updated successfully, but these errors were encountered: