Powers of expressions

[arnelg]

I imagine implementing positive powers, e.g., being able to do op^3 is straight forward and would be useful. It would also be fantastic to be able to do inverses, but that might complicate simplifications a lot? Even just inverses of expressions with numbers and parameters but no operators would be very useful, e.g.,

x = Pr"x"
(1+x)^(-1)

or 1//(1+x) or similar. Not sure if this is within scope.

[jfeist]

I added positive powers, which was indeed straightforward (in the full_rewrite branch).

Adding inverses or other operator functions (e.g., displacement or squeezing operators) would be really cool, but I don't see a good way to do this in the current architecture. Maybe after another rewrite at some point in the future, basing everything on Symbolics.jl or SymbolicUtils.jl (which were not available when I started this, AFAIK).

[jfeist]

FYI: I just released v1.0.0, which is based on the full_rewrite branch. Now a simple ]add QuantumAlgebra is again sufficient to install the latest version.

[arnelg]

Thanks for implementing that. I see that SymPy is also available in Julia. I don't know what is the preferred symbolic package. Do you use some package to deal with the number-and-parameter (i.e., non-operator) part of an expression?

[jfeist]

Well, SymPy.jl is just a wrapper around the python package, so it would introduce a dependency on PyCall, I'd much prefer not to do that. Right now, everything is dealt with within the logic of QuantumAlgebra itself, and numbers are just prefactors. I'm not sure if any of the symbolics packages support symbolic indices, i.e., things like

julia> using QuantumAlgebra; QuantumAlgebra.auto_normal_form()
julia> a(:i)*adag(:j)
δ(ij) + a†(j) a(i)

and analytic sums over them. I saw that SymPy has Indexed objects (https://docs.sympy.org/latest/modules/tensor/indexed.html), but repeated indices automatically imply summation, and this is just a special type of object, while indices are deeply integrated with all QuantumAlgebra objects.

[arnelg]

I see. Yeah, the indexing and formal sums seems very powerful (I have not used this feature yet myself).

[albertomercurio]

Hello, I also need to divide by a parameter, but actually it only supports multiplication.

Thank you for this amazing Package, because it simplied a lot my life. However, I'm now in the condition in which I need to divide by a parameter and it gives me an error.

Is there any way to fix it?

[jfeist]

Hi Alberto, this is indeed not supported for now. If you only need division by parameters (as opposed to operators), that should be possible to implement, but would still require significant changes in the code. I definitely have it in mind, but I'm not sure if I'll have time to implement this anytime soon. Could you give a concrete example of what you are trying to achieve? Maybe there's some workaround that would allow you to proceed without implementing division in general.

[Lightup1]

Hi @jfeist . I have an example needing division by parameters. As for dispersive coupling, you introduce a parameter $$\epsilon=\frac{g}{\Delta}\ll 1,$$ where $g$ is the coupling rate and $\Delta$ is the detuning. Let's assume that there is an expression $f(\epsilon,g,\Delta)$ and we need to simplify $f$ with $\epsilon$ substituted by $g$ and $\Delta$. Currently without parameter division, I need to rewrite the relation as $$g=\Delta \epsilon,$$ which resluts a complex expression $f(\epsilon,\Delta)$. In this case, I think that making normal_form function be able to compact substitution rule is a good choice to solve many problems involving parameter divisions.

[jfeist]

Hi, this would indeed be nice to have, but quite a bit of work to implement. For now, there is an (I think) reasonable workaround, please see the discussion in #15 for details - the filter_xxinv should do what you want. Note that if you use Pr"Δ^{-1}" for the inverse parameter, the (latex) output looks nicer for terms where it survives (but notice that the exponent -1 is just part of the parameter name to get nice latex output, it has no semantic meaning).

BTW, it looks to me like you might want to do approximations such as dropping terms where $\epsilon^2$ shows up etc - using the filter_xxinv function as a template, it would be straightforward to write a function that does this. Let me know if it's the case and you need help with that.

[Lightup1]

Thanks for your quick reply and solution @jfeist . I just tried filter_xxinv. It works good for inverse parameter like Pr"Δ^{-1}". How about a more complex situation where I have g_i=Pc"ϵ_i"*(Pr"ω"-Pr"ω_i"); with i=1,2? In this situation, I got a long expression like

And I want to substitute all $\epsilon_i$ here by $g_i$, $\omega_i$ and $\omega$, make the expression find a way to factorize $\omega-\omega_i$ and then simplify the expression. Is there a workaround to do that?

[Lightup1]

I just found that if I substituted $\omega_i$ with $\omega+\Delta_i$ , I would use Pr"Δ^{-1}" with filter_xxinv directly to simplify the expresion. Hope there is a way to make it more intelligent.🤣

[jfeist]

Unfortunately, for now these kinds of things are the best you can do in some sense. In the longer term, I think what would be necessary is to interface the library with Symbolics.jl or similar to get "real" symbolic manipulation features. I see two ways to do so: 1) Rewrite the whole library to be based on Symbolics.jl itself, which would make it necessary to add non-commuting operators to it, implement their commutation rules etc. This was not an option when I started developing QuantumAlgebra, and I haven't looked into Symbolics.jl in enough detail to know how feasible it would be nowadays without losing significant speed, and/or without losing the symbolic sums over indices. Both of these are important for many of the use cases that I cared about when writing the library, but might not matter for many other users. 2) Write some adapter that converts QuantumAlgebra.jl expressions to Symbolics.jl ones, simplify them within that, and then revert them back to QuantumAlgebra ones. The advantage would be that it might be possible to do this without implementing the commutator algebra in Symbolics.jl, as long as you find a way to ensure that it doesn't commute non-commuting operators (a simple trick would be to convert each product of quantum operators to a single object). This is certainly some work, but a prototype that works for some cases could probably be hacked together in a few afternoons.

[jfeist]

An update on this: version v1.4 of QuantumAlgebra now actually supports interoperability with Symbolics.jl and SymPy much better, although in a limited form: The scalar prefactors of each quantum expression can be any expressions from these systems (which can then be manipulated arbitrarily). This should cover a large fraction of use cases, especially if no symbolic index manipulations are needed for these parameters - in such cases, variables from Symbolics.jl provide much more flexibility than the "native" QuantumAlgebra parameters.