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
Although there are already some ideas in #3, we should have more fine-grained discussion on the content of QuBase. Maybe we can use this issue to collect some ideas and refine the roadmap in #3.
The following four points are probably uncontroversial and partly contained in #5.
Abstract types for bases and quantum arrays + interface.
QuArray and FiniteBasis related:
array-like functions/operations: +,-,* etc (it would be nice to have mutating functions as well, like A_mul_B!)
some matrix functions (expm)
basis-related functions/operations
Operator related:
convenience constructors: creation/annihilation (raiseop/lowerop), momentum and position,
displacement and squeezing operators
more operators: angular momentum operators, Pauli spin matrices, etc
special operations: partial trace and partial transpose
State related:
convenience constructors: state vectors (statevec) and density matrices, coherent and squeezed states
spectral decomposition of density matrices
state properties: purity, fidelity
expectation value and variance of a given operator and state
(Some of the functions in 3 & 4 could probably be taken from QuDOS.)
Additionally we could include the following aspects, but might put them into separate packages eventually:
more functions for quantum correlations and state distinguishability
State representation/visualization:
Husimi function, Wigner distribution, Glauber P function
Gaussian states, Yurke states, stretch states
More visualization/plot functions to explore the geometry of quantum states and operators (Such as states on the Bloch sphere).
Basically anything else should IMO first be developed in a separate packages. In particular with propagators we need to experiment a bit more to find a reasonable (and generic) interface. (Note: If we do it right, we can use QuArrays with ODE solvers from ODE.jl and exmpv from Expokit.jl without much trouble. So the propagation itself is "easy", but finding a good way to switch between methods and pass parameters is tricky).
[EDIT: I added some points from @Qi's comment below.]
Although there are already some ideas in #3, we should have more fine-grained discussion on the content of QuBase. Maybe we can use this issue to collect some ideas and refine the roadmap in #3.
The following four points are probably uncontroversial and partly contained in #5.
QuArrayandFiniteBasisrelated:+,-,*etc (it would be nice to have mutating functions as well, likeA_mul_B!)expm)raiseop/lowerop), momentum and position,displacement and squeezing operators
statevec) and density matrices, coherent and squeezed states(Some of the functions in 3 & 4 could probably be taken from QuDOS.)
Additionally we could include the following aspects, but might put them into separate packages eventually:
Basically anything else should IMO first be developed in a separate packages. In particular with propagators we need to experiment a bit more to find a reasonable (and generic) interface. (Note: If we do it right, we can use
QuArrays with ODE solvers fromODE.jlandexmpvfromExpokit.jlwithout much trouble. So the propagation itself is "easy", but finding a good way to switch between methods and pass parameters is tricky).[EDIT: I added some points from @Qi's comment below.]