-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Types/labels indicating quantum pictures #8
Comments
Hmmm. We're talking about the same types of quantum objects no matter which picture we're in - what changes is those objects' dynamical behavior with respect to each other. In that sense, I'm not sure that a picture is a "property" of any quantum object, but rather a specification on how we define that object's dynamic relationship to other objects. Perhaps the solution, then, is to namespace picture-specific functions by putting them in submodules; then you could define The above is a pretty silly example, since if that's all we were going to do we could just utilize multiple dispatch to have (Note: when I say quantum object, I mean states and operators.) |
The idea of tagging pictures makes sense only when we have propagator or evolution operator defined in a quantum dynamics calculation. We can consider the following scenario that a user defines the Hamiltonian with a Schrodinger picture tag, then the evolutionary operator or the propagator as a function of a given time list can be generated, then he can define all the other quantum operators he needs in the Schrodinger picture simply and clearly without involving any time-dependent parts. After that, he wants to calculate the time evolution of the expectation value of the particle number operator in the Heisenberg picture, and hence he can just switch the picture label and plug the initial state, the propagator and the number operator into an equation of motion solver and retrieve the result in the Heisenberg picture. Now he wants to calculate how the state of the system evolve in the Interaction picture. He can just point out to the computer the propagator and the bare Hamiltonian for the system, and switch the workspace to be Interaction picture, the transformation relationship between Heisenberg and Interaction picture is uniquely defined by the QuBase.jl he is using. When he inserts the input operators and states into some dynamics solver, he just use the operators and states that have been defined initially in the Schrodinger picture and the output objects will be automatically aligned to the Interaction picture as he wants. In the last step, the solver just recall QuBase.jl to do the switching work. In this way, users of the programs do not need to redefine operators and states separately when switching representations as a result of tagging picture labels to the workspace. Do you guys think this is useful and implementable? It hasn't been clear to me how should we easily implement this feature. The label may not necessarily be a global variable, it could be just attached to particular quantum objects. But here are the things in my mind we need to work out for the minimum of work/requirements:
|
Like you both said, the different pictures only make sense if you have information about the time evolution. A quantum object given by a
Then you could for instance define multiplication, such that |
What about the following?
Parameterizing the picture type would also allow users to easily define new subtypes of Would having efficient composable propogators as the above multiplication implies be out of the question for modern solvers? It would be really cool if we could realize a tensor product structure for propogators, though my knowledge here is weak (i.e. |
Using a Type parameter seems to be a better solution. But in any case we need to have a propagator type before we can work out the details. Note that composability of propagators is a different issue. If you have an operator in the Heisenberg picture
since The tensor product of the two Heisenberg operators would amount to (denoting the tensor product by
Where I added subscripts to the propagators to distinguish them. I am not sure one can in general implement the tensor product of individual (numerical) propagations, but this is a question of realizing the propagators. |
As discussed in #7, we may want to define types/labels to denote quantum pictures of the workspace. Transformation of propagators and states between different pictures may be also helpful.
The text was updated successfully, but these errors were encountered: