You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I remember this coming up before, and I believe it was decided to allow this, and that's why Moment has a field that preserves op insertion order.
A probably minor residual problem is that this allowance is inconsistent with circuit creation, alignment, transformers, and such. These all assume that ops that overlap on measurement keys must go into different moments.
This caused a subtle bug in align_right, which reverses the moments, calls align_left, and then reverses again. But if two measurements on the same key are in the same moment, then align_left will put them in different moments, and when the circuit is reversed again, those two ops will have swapped in order. #6899 fixes it by swapping order of ops within the moments too, BUT, any call to align_left (and thus to align_right too) will still split the measurements into separate moments, which maybe is different from what the user intended.
Just about all calls to transformers will do the same. Is this okay? Or should we be consistent here? How do we infer user intent? Should append and insert and all the transformers have a flag as to whether measurements and/or controls on the same key can share Moments? Should the circuit have that as a member variable? Or is the ROI to explicitly handle this too low?
The text was updated successfully, but these errors were encountered:
daxfohl
changed the title
Consistency around multiple measurements on a key in the same Moment
Consistency around multiple measurements to the same key in the same Moment
Jan 1, 2025
I remember this coming up before, and I believe it was decided to allow this, and that's why
Moment
has a field that preserves op insertion order.A probably minor residual problem is that this allowance is inconsistent with circuit creation, alignment, transformers, and such. These all assume that ops that overlap on measurement keys must go into different moments.
This caused a subtle bug in
align_right
, which reverses the moments, callsalign_left
, and then reverses again. But if two measurements on the same key are in the same moment, thenalign_left
will put them in different moments, and when the circuit is reversed again, those two ops will have swapped in order. #6899 fixes it by swapping order of ops within the moments too, BUT, any call toalign_left
(and thus toalign_right
too) will still split the measurements into separate moments, which maybe is different from what the user intended.Just about all calls to transformers will do the same. Is this okay? Or should we be consistent here? How do we infer user intent? Should
append
andinsert
and all the transformers have a flag as to whether measurements and/or controls on the same key can share Moments? Should the circuit have that as a member variable? Or is the ROI to explicitly handle this too low?The text was updated successfully, but these errors were encountered: