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
Add a function (or enhance an existing one) to RotatingFrame that is qiskit.quantum_info "type aware", to be used at a higher level so that a user doesn't need to change syntax based on type.
Currently RotatingFrame has a bunch of frame-transformation helper functions that explicitly perform certain mathematical operations, e.g.:
rotating_frame.state_into_frame(t, y)
performs the mapping t, y -> exp(-tF) @ y and
rotating_frame.operator_into_frame(t, y)
performs the mapping t, y -> exp(-tF) @ y @ exp(tF) (might have minus signs mixed up).
Currently, if a user has a Statevector instance, they need to call state_into_frame, but if they have a DensityMatrix, they need to call operator_into_frame to perform the correct transformation. Furthermore, all current functions will strip any wrapping, and return a raw array. Note as well that the terminology of these functions is meant more to differentiate between the mathematical transformations, rather than to align with standard quantum usage (e.g. a DensityMatrix is a "state").
It'd be great to have something higher level, like rotating_frame.into_frame(t, y) (and similarly rotating_frame.out_of_frame(t, y), which utilizes the type of y to determine the correct mathematical transformation, and returns the results in the original wrapped class.
The text was updated successfully, but these errors were encountered:
What is the expected behavior?
Add a function (or enhance an existing one) to
RotatingFrame
that isqiskit.quantum_info
"type aware", to be used at a higher level so that a user doesn't need to change syntax based on type.Currently
RotatingFrame
has a bunch of frame-transformation helper functions that explicitly perform certain mathematical operations, e.g.:performs the mapping
t, y -> exp(-tF) @ y
andperforms the mapping
t, y -> exp(-tF) @ y @ exp(tF)
(might have minus signs mixed up).Currently, if a user has a
Statevector
instance, they need to callstate_into_frame
, but if they have aDensityMatrix
, they need to calloperator_into_frame
to perform the correct transformation. Furthermore, all current functions will strip any wrapping, and return a raw array. Note as well that the terminology of these functions is meant more to differentiate between the mathematical transformations, rather than to align with standard quantum usage (e.g. aDensityMatrix
is a "state").It'd be great to have something higher level, like
rotating_frame.into_frame(t, y)
(and similarlyrotating_frame.out_of_frame(t, y)
, which utilizes the type ofy
to determine the correct mathematical transformation, and returns the results in the original wrapped class.The text was updated successfully, but these errors were encountered: