Make quantum algebra separate package?

[oameye]

I would like to borrow the quantum symbolics of this package to build my own package on top of. Are there any plans to make the symbolics its own package?

[oameye]

@david-pl @ChristophHotter @Krastanov I noticed that there is a lot of integration with QuantumSavory and QuantumOptics. Are there any plans to move the symbolics representation to QuantumSymbolics.jl?

[Krastanov]

David and I have briefly brought up the possibility to use QuantumSymbolics as a universal interface for many of these packages. That type of work is underway (QuantumSymbolics already has extensions to convert into QuantumOptics and into QuantumClifford, and a bounty for developing an extension for conversion into QuantumCumulants).

QuantumSymbolics also is inspired by some of the work done here, but aims to be more general. QuantumSymbolics leans heavily into the basis-defining infrastructure from QuantumOptics.

I however do not expect any of the internals of QuantumCumulants to start depending on QuantumSymbolics -- QuantumCumulants is designed to be efficient at what it does (a fairly single-purpose focus), while QuantumSymbolics will definitely not be as fast at it.

[oameye]

I am writing a package myself which computes Floquet perturbative expansions to compute effective Hamiltonians for time-periodic systems. QuantumCumulants contains a lot of the foundation to do this. I am happy to depend on QuantumCumlants, as it adds directly the computation of the associate mean-field equation.

If there any plans to isolate the symbolic infrastructure I am happy to help in the endeavor.

QuantumCumulants is designed to be efficient at what it does (a fairly single-purpose focus), while QuantumSymbolics will definitely not be as fast at it.

In the end, QuantumCumulants builds a non-commutive algebra with SymbolicUtils. Isn't QuantumSymbolics doing the same? Why would it be slower? In what way is QuantumCumulants optimised?

bounty for developing an extension for conversion into QuantumCumulants.

Interesting, I would be willing to look into this. :)

[Krastanov]

In the end, QuantumCumulants builds a non-commutive algebra with SymbolicUtils. Isn't QuantumSymbolics doing the same? Why would it be slower? In what way is QuantumCumulants optimised?

QuantumCumulants needs tensor products over a couple of simple Hilbert spaces, commutation rules, and expectation values. QuantumSymbolics covers traces, partial traces, determinants, a plethora of nestings of such expressions with tensor products and linear algebra "application" products, inner products, superoperators, and more. It is quite possible to make QuantumSymbolics as fast as QuantumCumulants in the domain in which QuantumCumulants is applicable, but that is currently not an active project (mostly because QuantumCumulants already exists).

I believe that if your priority is high productivity in developing your near-term research work, sticking to QuantumCumulants for the project you described is optimal. If there is a consideration of longer-term unification of interfaces and packages, QuantumSymbolics is probably a better choice, but such a choice comes with the need to invest more work in developing QuantumSymbolics. If you and/or your colleagues of yours are interested in helping with that, I do have funding for bounties related to such developments (https://github.com/QuantumSavory/.github/blob/main/BUG_BOUNTIES.md)

[Krastanov]

And while I can not speak for the QuantumCumulant devs, I expect that if you decide to factor out a small symbolics core out of QuantumCumulants, most people will be supportive of the idea (but will probably not have much time to contribute dev effort).

[david-pl]

I would like to borrow the quantum symbolics of this package to build my own package on top of. Are there any plans to make the symbolics its own package?

TL;DR

We never needed it, but feel free to do it ;)

The long version

I've thought about this, but the symbolic algebra as defined in QuantumCumulants didn't strike me as generic enough to warrant an abstracted package. There are a few key things that QuantumCumulants does differently.

In the end, QuantumCumulants builds a non-commutive algebra with SymbolicUtils. Isn't QuantumSymbolics doing the same? Why would it be slower? In what way is QuantumCumulants optimised?

Strictly speaking, that's not true. QuantumCumulants defines it's very own symbolic, non-commutative, algebra which works without SymbolicUtils. We do use some method definitions to make it behave the same, but under the hood, everything that's non-commutative (<:QNumber) is defined in QuantumCumulants.

The reason behind this is that QuantumCumulants focuses on applying commutation relations. All symbolic QNumber expressions you build with QuantumCumulants are re-written (on construction) in a way that makes applying commutation relations easy. Applying commutation relations in this context means re-writing an expression using its commutator such that the resulting expression is normal ordered. For example, the product $aa^\dagger$ is always written as $a^\dagger a + 1$. That is necessary since you need to make sure that all commutation relations that can be applied are applied before using the cumulant expansion up to a certain order. Otherwise, neglecting higher order terms yields incorrect equations.

This goes a bit against what symbolic simplification usually does. Consider, for example, the expression $a \left( a + a^\dagger\right)$. In usual symbolic simplification, this would be fine, since all terms are neatly "collected". However, there is a commutation relation here we need to apply, which is why QuantumCumulants immediately expands the product and replaces the appearing $aa^\dagger$.

In that sense, the algebra in QuantumCumulants is quite opinionated. It's not generic because you can never really construct an expression such as $aa^\dagger$ since it's immediately re-written. There are a few more re-writing rules, such as:

• Products are immediately flattened.
• Products of sums are always expanded, i.e. a product can never consist of an addition, but an addition can consist of multiply products.
• Commutation relations are always applied.

The list is not exhaustive. These rules make it very simple to apply all commutators that you can and it's much more efficient than working with a generic rule re-writing engine.

Note that all of this happens before averaging a q-number expression, however. Once you average a QNumber expression, you are just left with expressions containing (complex) numbers. So after averaging, the result is a SymbolicUtils expression.

QuantumSymbolics, on the other hand, allows you to construct arbitrary expressions and simplify them with a custom and/or pre-defined set of re-writing rules. None of those have to involve commutation relations. Furthermore, they can easily be converted to QuantumOptics or QuantumClifford expressions.

All that being said, I'm not opposed to factoring out the symbolic algebra here, if you rely on some of the behavior (normal-ordering, applying commutation relations). Which parts of QuantumCumulants do you require? The biggest gain, IMO, would be if you can abstract things such that the new base package doesn't depend on MTK and OrdinaryDiffEq in any way, since these are pretty large dependencies. Is that even possible? Other than slimming down dependencies, I don't really see the point in abstracting things.