Conversion from symbolic object to numeric objects from the QuantumToolbox.jl library (by implementing a backend for the `express` API)

[Krastanov]

This is one of 3 independent bounties which share the type of work that needs to be done:

• Conversion from symbolic object to numeric objects from the QuantumToolbox.jl library (by implementing a backend for the express API) #116 on interfacing with QuantumToolbox.jl
• Conversion of symbolic objects to "lazy" QuantumOptics.jl numerical objects #117 on improving the interface that already exists for QuantumOptics.jl
• Conversion of symbolic objects to base linear algebra objects (vectors, matrices, sparse matrices, etc) #118 on using the already existing QuantumOptics.jl interface to provide an interface for unstructured "naked" state vectors and operators

One of the main value-adds of QuantumSymbolics.jl is to enable converting symbolic expressions into the appropriate numerical representation for use with a variety of simulators. We have such capabilities with respect to a few simulators now, e.g. converting the symbolic Z1 into either a Ket (from QuantumOptics.jl) or a Stabilizer tableau (from QuantumClifford.jl). Here is an example:

julia> using QuantumSavory, QuantumOpticsBase, QuantumClifford

julia> express(X1, QuantumOpticsRepr())
Ket(dim=2)
  basis: Spin(1/2)
 0.7071067811865475 + 0.0im
 0.7071067811865475 + 0.0im

julia> express(X1, CliffordRepr())
𝒟ℯ𝓈𝓉𝒶𝒷
+ Z
𝒮𝓉𝒶𝒷
+ X

This bounty is on introducing symbolic-to-numeric conversion capabilities for the QuantumToolbox.jl library

About QuantumToolbox.jl: QuantumToolbox.jl is a recent alternative to QuantumOptics.jl with very similar capabilities. It would be useful for crosschecks and overall ecosystem health to support QuantumToolbox.jl for symbolic-to-numerical conversions. A big difference between the two libraries is that QuantumOptics.jl enforces a notion of a semantic basis (e.g., a Fock basis is different from a spin basis of the same number of dimensions), while QuantumToolbox.jl has a much flatter inner structure for its states and operators. Nonetheless, given the significant similarities, one can structure the implementation very similarly to the one for QuantumOptics.

express is the main API through which conversion of symbolic to numeric objects happens. It runs recursively through the symbolic expression tree, converting the leaves of the tree and then moving towards the root by converting each subtree. Internally, it can use a cache to avoid repeated conversion of the same object.

At its most basic, this bounty would require making express(some_symbolic_object, QuantumToolboxRepr()) to return an appropriate numerical representation of the symbolic object some_symbolic_object. Most of the work would be copying and minorly modifying the existing implementation for QuantumOptics.jl, working mostly with the internal express_nolookup (which is the non-caching basic version of express).

The most useful references would be:

• what is the express API that is used for conversion from symbolics to numerics
• how express is implemented for QuantumOptics
• the overall documentation of QuantumSymbolics
• conditionally loaded package extensions in julia which is how we have structured the dependencies on various external libraries in QuantumSymbolics

For this bounty to be completed, one would need:

• matching the express capabilities that exist for QuantumOptics.jl, but now for QuantumToolbox.jl
• preparing the implementation in the form of a package extension (as is done for QuantumOptics)
• adding tests for correctness, potentially comparing numerical representations between the existing QuantumOptics and the new backend for QuantumToolbox
• a brief mention of the new backend in the documentation, e.g. towards the bottom of the front page of the docs

If you are new to julia, make sure to:

• install julia using juliaup for version management
• look through the julia manual and modern workflows
• try out VSCode with the Julia plugin for good IDE support