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.
What is the expected behavior?
Add a function (or enhance an existing one) to
RotatingFramethat 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
RotatingFramehas a bunch of frame-transformation helper functions that explicitly perform certain mathematical operations, e.g.:performs the mapping
t, y -> exp(-tF) @ yandperforms the mapping
t, y -> exp(-tF) @ y @ exp(tF)(might have minus signs mixed up).Currently, if a user has a
Statevectorinstance, they need to callstate_into_frame, but if they have aDensityMatrix, they need to calloperator_into_frameto 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. aDensityMatrixis 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 ofyto determine the correct mathematical transformation, and returns the results in the original wrapped class.