Skip to content
This repository was archived by the owner on Mar 14, 2026. It is now read-only.
This repository was archived by the owner on Mar 14, 2026. It is now read-only.

Scope of QuBase.jl #7

Description

@acroy

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.

  1. Abstract types for bases and quantum arrays + interface.
  2. 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
  3. 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
  4. 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:

  1. Quantum information related:
    • special states: W, GHZ, Bell states etc
    • entanglement measures: negativity, concurrence etc
    • more functions for quantum correlations and state distinguishability
  2. 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.]

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions