Quantum operator algebra

[nikolas]

Hi,

if you guys are generally open to the idea, I would very much like to integrate/refactor most of the symbolic code from my own quantum optical circuit package QNET [1] into SymPy over the next few months.

Specifically, this would probably lead to some completely new modules to handle quantum optical circuits (these are very different from the circuit representation used in quantum information algorithms, for more information see this paper [2] or the documentation [1] or my brief intro below) as well as contributions to sympy.physics.quantum and sympy.physics.secondquant.py

I guess, to get started, it would be very helpful for me to know who I could ask questions about the existing code (Brian and Aaron, you might still remember me from this year's SciPy) and what the general policy is on extending existing classes, and perhaps even modifying some of the design decisions/philosophy.

First off, I know that a lot of people have put _tons_ of work into this and that the design decisions that were made so far were made for good reasons. I certainly don't wish to step on people's toes, but rather try to find a way in which I can contribute useful code to what I believe is an awesome project. 

So, to start off, let me very briefly describe what sort of systems we study and what our workflow looks like.

We generally study interconnected networks of open quantum systems where the connections are realized by freely propagating 1-d bosonic quantum fields. 

A particular node in a network analyzed in isolation would have some internal Hilbert space H_j and its ensemble averaged dynamics would be computed through a Lindblad-type master equation.

Now the math behind the circuit algebra that we use allows to combine multiple such systems and derive the model for the composite system.

This beast now has as its internal Hilbert space the tensor product of its components H_1 (x) H_2 (x) ... (x) H_n and it could in principle be embedded into an even larger circuit.

As a consequence, the quantum operators appearing in the overall circuit models are usually polynomials in operators that act non-trivially only on specific degrees of freedom.

E.g. if component j were an optical cavity that contains a single harmonic oscillator degree of freedom, then there would be an associated pair of creation and annihilation operators a_j, Dagger(a_j).

If we consider a single product M_1 (x) N_2, i.e. an operator M acting on the degree of freedom labelled 1 and N acting on 2,  there are two basic ways to implement operators on such a tensor space structure. 

1. For any single degree of freedom operator M_1 to be considered in a composite system, it needs to be explicitly lifted to the whole tensor space by tensor-multiplying it with identity operators for all remaining degrees of freedom:
      M_1 -> M_1 (x) Id_2
      N_2 -> id_1 (x) N_2
2. Each single degree of freedom operator only keeps track of its associated Hilbert space and commutes with operators acting on other degrees of freedom.
   M_1 stays M_1, N_2 stays N_2 and only when they are multiplied, their product is considered to act non-trivially on both 1 and 2.
   Their product would simply be written as
   M_1 * N_2 
   with the fact that this is a tensor product being implicit in their acting on different degrees of freedom.

As it stands, the classes and methods within sympy.physics.quantum basically follow approach 1) whereas sympy.physics.secondquant appears to follow 2).

The advantages of 1) are:

- It's very simple to resolve commutation issues for operators on independent degrees of freedom

- The normal form, e.g. for the above example is given naturally

- It is trivial to resolve how such an operator acts on a given Hilbert space vector because that vector needs to be defined as a sum over similar tensor products.

- It is very easy to compute the numerical representation in a given basis and do things like interfacing with QuTiP [3].

The advantages of 2) are:

- It is very easy to scale up to very many degrees of freedom without cluttering your expressions

- The notation is much more like most people write quantum operator expressions by hand

- There need not be two different operations for multiplications (within a degree of freedom) and tensor products

- Even when working with a many component system it is trivially easy to obtain operator expressions that are restricted to only subsets of the overall system, i.e. each operator implicitly is defined on ANY additional degrees of freedom you might still add to your problem

I guess my main question is, is there any chance you would be open to making everything effectively follow the second approach? 

Or is there some way you can see to make sympy.quantum.operator types optionally have a Hilbert space property that would me to re-use everything defined in that module?

I know this must sound pretty drastic, but if we could find an approach to this that works for everybody, you would gain at least one (probably more) very motivated contributors to this part of SymPy.

Obviously I would be happy to do all the work myself to prepare these changes.

QNET also has some additional features you might find useful, there are some capabilities for recursive pattern matching / replacement with wildcards that can stand for single, zero or more or one or more operands. Similar to x_, x__, x___ in mathematica. It also supports limiting the types of matched symbols and can handle where a matched symbol must appear multiple times. Like Add(x_, Times(5, x_)) matches q+(5*q) but not q+(5*r).

If this doesn't already exist, I'd be happy to contribute these things to SymPy over time or maybe at least help whoever else is working on these.

Brian has already asked me to re-license QNET under MIT/BSD which I intend to do with the next full release (which, if we can agree on the above might be the last release of QNET that still features the general purpose quantum operator algebra code).

Thanks!

Nikolas

[1] QNET: http://mabuchilab.github.io/QNET/

[2] SLH models and networks of quantum optical systems http://arxiv.org/abs/0707.0048

[3] QuTiP: http://qutip.org/

[Ondřej Čertík]

Hi Nikolas,

On Tue, Nov 4, 2014 at 2:05 PM, nikolas <nikola...@gmail.com> wrote:
> Hi,
>
> if you guys are generally open to the idea, I would very much like to
> integrate/refactor most of the symbolic code from my own quantum optical
> circuit package QNET [1] into SymPy over the next few months.
> Specifically, this would probably lead to some completely new modules to
> handle quantum optical circuits (these are very different from the circuit
> representation used in quantum information algorithms, for more information
> see this paper [2] or the documentation [1] or my brief intro below) as well
> as contributions to sympy.physics.quantum and sympy.physics.secondquant.py

That would be awesome, looking forward.

>
> I guess, to get started, it would be very helpful for me to know who I could
> ask questions about the existing code (Brian and Aaron, you might still
> remember me from this year's SciPy) and what the general policy is on
> extending existing classes, and perhaps even modifying some of the design
> decisions/philosophy.
>
> First off, I know that a lot of people have put _tons_ of work into this and
> that the design decisions that were made so far were made for good reasons.
> I certainly don't wish to step on people's toes, but rather try to find a
> way in which I can contribute useful code to what I believe is an awesome
> project.

No worries of stepping on people's toes. I think everybody is open to
new ideas to redesign anything in sympy if you got a better idea than
what is implemented in there already.

I don't have an opinion on this personally. Brian would be the guy to ask.
If you want, we can try to schedule a G+ hangout with Brian about this.

>
> I know this must sound pretty drastic, but if we could find an approach to
> this that works for everybody, you would gain at least one (probably more)
> very motivated contributors to this part of SymPy.
> Obviously I would be happy to do all the work myself to prepare these
> changes.
>
> QNET also has some additional features you might find useful, there are some
> capabilities for recursive pattern matching / replacement with wildcards
> that can stand for single, zero or more or one or more operands. Similar to
> x_, x__, x___ in mathematica. It also supports limiting the types of matched
> symbols and can handle where a matched symbol must appear multiple times.
> Like Add(x_, Times(5, x_)) matches q+(5*q) but not q+(5*r).
> If this doesn't already exist, I'd be happy to contribute these things to
> SymPy over time or maybe at least help whoever else is working on these.

That would be awesome, if you could implement these features to sympy. A lot
of people could use those.

>
> Brian has already asked me to re-license QNET under MIT/BSD which I intend
> to do with the next full release (which, if we can agree on the above might
> be the last release of QNET that still features the general purpose quantum
> operator algebra code).

Very cool, I was about to ask the same question. If you got some
contributions from
other people that are only GPL licensed, you need to obtain
permissions from them
to relicense to BSD or MIT.

From the next sympy release, we are trying to make it easier for
people to have separate
projects that use sympy, as well as allow dependencies for sympy, like
mpmath. Depending
on your goals, if QNET has lots of specialized numerical code, it
might be better for that
part to be a separate package. For example with PyDy, the symbolic
parts are all in sympy,
but specialized code (things like visualization or some specialized
code generation) is maintained outside of sympy.

Ondrej

>
> Thanks!
>
> Nikolas
>
>
> [1] QNET: http://mabuchilab.github.io/QNET/
> [2] SLH models and networks of quantum optical systems
> http://arxiv.org/abs/0707.0048
> [3] QuTiP: http://qutip.org/
>

> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sympy+un...@googlegroups.com.
> To post to this group, send email to sy...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sympy.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/6ee17ea7-30bd-491e-837d-6e9041145f66%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Aaron Meurer]

Hi Nikolas. I definitely remember you and your talk from SciPy. 

I think the only person who knows about the quantum code is Brian. I don't want to speak for him, but he is typically very busy with IPython stuff, and not able to do a whole lot with SymPy these days. Unfortunately, the set of people with the appropriate domain knowledge to understand the quantum module is very small (and it doesn't include me btw).  If you have time to work on this and want to go ahead and "take ownership" of this particular part of SymPy, that is great. 

Regarding the philosophy, Brian will have to comment, but I'll refer you to look up the various pull requests (both open and closed) to SymPy's quantum module, as they had a lot of design discussions on them, as I remember.

Be careful to not conflate the two things. Mpmath is a dependency of SymPy, whereas SymPy would be a dependency of QNET and PyDy. You can already have projects that depend on SymPy. The SymPy community's approach to dependencies is irrelevant there. The thing that will be changing is SymPy's approach to dependencies of SymPy (and even there I'd like to feel things out slowly, so let's just start with mpmath).

Aaron Meurer

Ondrej

>
> Thanks!
>
> Nikolas
>
>
> [1] QNET: http://mabuchilab.github.io/QNET/
> [2] SLH models and networks of quantum optical systems
> http://arxiv.org/abs/0707.0048
> [3] QuTiP: http://qutip.org/
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sympy+un...@googlegroups.com.
> To post to this group, send email to sy...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sympy.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/6ee17ea7-30bd-491e-837d-6e9041145f66%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CADDwiVDN-CuHRPOaBTPk5m4Tw0KEjpV0ySncTsbLfzkZrsnGnA%40mail.gmail.com.

[nikolas]

Hey Aaron and Ondrej, 

thanks a lot for both of your replies!

Yes, I am certainly not proposing moving all of QNET into SymPy.

The other main components within QNET are mainly methods for describing circuits at a very high level, as well as providing a component library of models to be used for such circuits. For numerical simulations we already use QuTiP and custom codes that are independent packages.

I'm cc'ing Robert, the QuTiP author because he's contributed to the sympy.physics.quantum, as well.

The main reason for me writing my own algebra code back when I started QNET was hat I had a hard time understanding the right (i.e., fastest and least redundant) way to define my own custom algebras within sympy. For our project I needed various algebras, some of which had nothing to do with typical commutative or non-commutative algebra.

The implementation was partially inspired by Mathematica and the term rewriting system Maude where in either case, on can abstractly define new Operations to be commutative, associative, having a neutral element that should be filtered out or even an inverse, etc. In QNET such very common properties of an Operation are added to the implementing class via class decorators that operate on the operation's "args".

So, if there is general interest in these methods within SymPy and after I've had a chance to talk to more of the sympy.physics.quantum devs, maybe we could do the following:

1. Extend sympy.physics.quantum (and maybe integrate it with sympy.physics.secondquant) in a way that I can migrate my circuit model definitions to it more easily (see my previous email).
   
2. Add an adapted version of QNET's pattern matching facilties to a special (new? or existing) sympy module.
   
3. Brainstorm together on whether sympy would like to include some general purpose "custom algebra definition library" because I think this might be a use-case that's relevant to other re-searchers as well.
4. Add the basic quantum optical circuit library to sympy.physics(.quantum)

Then I could make QNET only contain the actual component models as well methods for parsing circuit definition files, etc.

@Brian and Robert, if you two had time to offer your input, that would be very highly appreciated.

Thanks!

Nikolas

[Francesco Bonazzi]

Concerning pattern matching and term rewriting, there is some work by Matthew Rocklin as separate modules (i.e. unrelated to the standard pattern matcher in sympy.core)

Unification:
http://matthewrocklin.com/blog/work/2012/11/01/Unification/
https://github.com/sympy/sympy/tree/master/sympy/unify

Strategies:
https://github.com/sympy/sympy/tree/master/sympy/strategies

He also wrote an independent library to all the definition of multiple dispatched functions in Python:
http://multiple-dispatch.readthedocs.org/en/latest/
https://github.com/mrocklin/multipledispatch

There was some discussion about including multipledispatch as a dependency in SymPy. I don't know what the conclusion was. Despite not being a pattern matcher, it could be very useful to define generic methods acting on different kinds of algebras based on Python's classes.

Currently the standard pattern matcher (the one defined in sympy.core) does not support assumptions on its wildcards, or at least whenever I tried them, they did not work. So if you declare

w = Wild('w', integer=True)

matches won't be restricted to integers only, unfortunately. Furthermore, the pattern matcher is sensible to additive and multiplicative inverses, so you're expected to get a lot more matches on the same expression than Mathematica.

In [21]: expr = 1/(x+y)

In [22]: expr.match(x+w)
Out[22]:
⎧          1  ⎫
⎨w: -x + ─────⎬
⎩        x + y⎭

In Mathematica w_ matches y so that x+w -> x+y.

[Nikolas Tezak]

Hey Francesco,

thanks for your reply! That is super interesting and is exactly the direction I meant.
Multiple dispatch indeed looks quite useful for general purpose algebra implementations.
Where could I find out more about the discussion of making it a sympy dependency?
And are there some examples for the sympy.strategies module?
Thanks,

Nikolas

> --
> You received this message because you are subscribed to a topic in the Google Groups "sympy" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/sympy/a4NS2taAvQ4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to sympy+un...@googlegroups.com.

> To post to this group, send email to sy...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sympy.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/3fb2c7b3-2ffc-4b68-8db0-fa3b26c3f457%40googlegroups.com.

[Francesco Bonazzi]

On Wednesday, November 5, 2014 9:02:23 PM UTC+1, nikolas wrote:

Multiple dispatch indeed looks quite useful for general purpose algebra implementations.
Where could I find out more about the discussion of making it a sympy dependency?

https://github.com/sympy/sympy/issues/7339
 

And are there some examples for the sympy.strategies module?

I know that one of its main implementations is the fu( ) function, which simplifies very complicated trigonometric expressions:

https://github.com/sympy/sympy/blob/master/sympy/simplify/fu.py

On mrocklin's blog:

http://matthewrocklin.com/blog/work/2012/11/07/Strategies/

[Nikolas Tezak]

Hey Robert,
thanks for your reply! That’s very cool.
I would very much like to join forces on sympsi, in that case!
I’ll check out the code and get back to you two!

Regarding explicit and implicit tensor products, I agree that it should be possible to allow for both.
We’ll figure something out :)
Best,


Nik


On Nov 5, 2014, at 11:20 PM, Robert Johansson <rob...@riken.jp> wrote:

> Hi Nikolas
>
> Great to hear that you’re interested in finding a common framework for symbolic quantum mechanics for QNET and the sympy quantum module! I think both projects would benefit from this.
>
> Me and a student here where I work (Eunjong Kim, cc:ed) are also working on extensions of the sympy quantum module. Currently our focus on bosonic and atomic systems, and we are working on methods for manipulating operator expressions, such as performing unitary transformations and generating Heisenberg and semiclassical equations of motion. For now we do this work in a separate project that we branched out from the sympy.quantum module, which we call sympsi:
>
> http://sympsi.github.io
>
> I hope we can contribute this work back upstream to sympy.quantum at some point, but for the time being we are doing this in a separate project because we needed a faster paced development repository. The activity level in sympy.quantum module is very low now, and pull requests takes a long time to get reviewed. For example, I currently have a PR with a small fix of a issue in the quantum module:
>
> https://github.com/sympy/sympy/pull/8264
>
> and it has been few weeks without having received any comments. I don’t mean to be critical or anything, but it is difficult to work and make progress with sympy.quantum if with this pace of development. So my current solution for this is to do experimental work on sympy.quantum in a separate project. Maybe this would not be necessary if more people get involved in sympy.quantum. But I also think it would be worth having a discussion on if the quantum module in sympy should really be a part of sympy or if we could collaborate more easily on symbolic quantum mechanics with Python in a separate project which has sympy as a dependency. There is no technical reasons for why the sympy.quantum module has to be included in sympy, and having it in sympy makes it difficult separately install updates in the quantum module. As it is now a user that want to use recent features from the quantum module has to install the development version of sympy from github. Either way, I’d be happy to work together symbolic quantum mechanics.
>
> Regarding your question about explicit tensor products (quantum module) and implicit tensor product (secondquant), and whether it would be possible to towards implicit tensor products in the quantum module: Personally I think that the quantum module must support both types of formalisms. When working only with operators it is convenient to use implicit tensor product, as you point out, and currently it is already possible to do this using the fermion and boson modules in sympy’s quantum module (as well as in secondquant), because different modes can be assigned labels that can be used to distinguish the modes (rather than their position in a tensor product). This is what I use in most of what I use sympy quantum for. But in my experience it is also very useful to allow explicit tensor products of operators in when working with different states for different components in composite quantum systems. So my vote is for not moving towards one formalism or the other, but rather support both of them. It shouldn’t be too difficult to do this, since there is already some support for this.
>
> As for the secondquant, I think it is a bit unfortunate to have two separate and incompatible frameworks for symbolic quantum mechanics in sympy, and I think it would be great if the the features of secondquant eventually could be moved into the quantum module, and perhaps then the secondquant module could be deprecated. The fermion and boson modules in the quantum module is a step in that direction, but there is more work required on this.
>
> Rob
> --
> Robert Johansson, Ph.D.
> iTHES Research Group, RIKEN
> rob...@riken.jp || http://jrjohansson.github.io/research.html

[Ondřej Čertík]

Hi Robert,

I noticed you didn't send this to the sympy list, but since it got
forwarded here, here are my replies:

On Thu, Nov 6, 2014 at 9:51 AM, Nikolas Tezak <nikola...@gmail.com> wrote:
> Hey Robert,
> thanks for your reply! That’s very cool.
> I would very much like to join forces on sympsi, in that case!
> I’ll check out the code and get back to you two!
>
> Regarding explicit and implicit tensor products, I agree that it should be possible to allow for both.
> We’ll figure something out :)
> Best,
>
>
> Nik
>
>
> On Nov 5, 2014, at 11:20 PM, Robert Johansson <rob...@riken.jp> wrote:
>
>> Hi Nikolas
>>
>> Great to hear that you’re interested in finding a common framework for symbolic quantum mechanics for QNET and the sympy quantum module! I think both projects would benefit from this.
>>
>> Me and a student here where I work (Eunjong Kim, cc:ed) are also working on extensions of the sympy quantum module. Currently our focus on bosonic and atomic systems, and we are working on methods for manipulating operator expressions, such as performing unitary transformations and generating Heisenberg and semiclassical equations of motion. For now we do this work in a separate project that we branched out from the sympy.quantum module, which we call sympsi:
>>
>> http://sympsi.github.io
>>
>> I hope we can contribute this work back upstream to sympy.quantum at some point, but for the time being we are doing this in a separate project because we needed a faster paced development repository. The activity level in sympy.quantum module is very low now, and pull requests takes a long time to get reviewed. For example, I currently have a PR with a small fix of a issue in the quantum module:
>>
>> https://github.com/sympy/sympy/pull/8264

It's in.

>>
>> and it has been few weeks without having received any comments. I don’t mean to be critical or anything, but it is difficult to work and make progress with sympy.quantum if with this pace of development. So my current solution for this is to do experimental work on

It is important that you ping reviewers to review your code. I have
asked you already to do that, e.g here:

https://github.com/sympy/sympy/pull/2692#issuecomment-32912971

We are all busy with our day jobs, just like you are. If you look at
the number of PRs in sympy:

https://github.com/sympy/sympy/pulls

There is over 160 open. Even if I spent only 15 min on each, it would
take 40h (i.e. a week full time) to review all of them, so I would
have to take a week vacation to do that. However, and that's the
beauty of opensource and a community, if each of us only reviews a
subset of PRs, then we can actually easily keep reviewing all of them.
Robert, you have already established yourself with many PRs in sympy
and because I am interested in quantum, all you have to do is to put
"@certik" in any PR you post, then I get an email in the inbox, and I
almost always reply within a day, usually sooner.

Other people, let's say with interest in integration, will ping other
people. The best is to ping people who contributed to the area of the
code that you are touching in the PR. You can use "git blame" to get
an idea.

Anyway, if you could please ping us the next time you send a PR, I can
guarantee you'll get a better experience.

> sympy.quantum in a separate project. Maybe this would not be necessary if more people get involved in sympy.quantum. But I also think it would be worth having a discussion on if the quantum module in sympy should really be a part of sympy or if we could collaborate more easily on symbolic quantum mechanics with Python in a separate project which has sympy as a dependency. There is no technical reasons for why the sympy.quantum module has to be included in sympy, and having it in sympy makes it difficult separately install updates in the quantum module. As it is now a user that want to use recent features from the quantum module has to install the development version of sympy from github. Either way, I’d be happy to work together symbolic quantum mechanics.

Yes, that's a valid point, see our conversation above. There are pros
and cons of each approach. Some pros of being separate is that you can
possibly develop faster as well as only update you module and work
with any stable branch of sympy (as you mentioned). Pros of being
inside sympy is that you get wider exposure and if it is a code that
only gets updated a few times a year, you essentially get free
maintenance form the rest of the sympy crew.

>>
>> Regarding your question about explicit tensor products (quantum module) and implicit tensor product (secondquant), and whether it would be possible to towards implicit tensor products in the quantum module: Personally I think that the quantum module must support both types of formalisms. When working only with operators it is convenient to use implicit tensor product, as you point out, and currently it is already possible to do this using the fermion and boson modules in sympy’s quantum module (as well as in secondquant), because different modes can be assigned labels that can be used to distinguish the modes (rather than their position in a tensor product). This is what I use in most of what I use sympy quantum for. But in my experience it is also very useful to allow explicit tensor products of operators in when working with different states for different components in composite quantum systems. So my vote is for not moving towards one formalism or the other, but rather support both of them. It shouldn’t be too difficult to do this, since there is already some support for this.
>>
>> As for the secondquant, I think it is a bit unfortunate to have two separate and incompatible frameworks for symbolic quantum mechanics in sympy, and I think it would be great if the the features of secondquant eventually could be moved into the quantum module, and perhaps then the secondquant module could be deprecated. The fermion and boson modules in the quantum module is a step in that direction, but there is more work required on this.

I think it's always great to try new ideas outside of sympy, since you
don't need to get any reviews and you can just try things and
experiment with things and figure out what approach is more promising
and what approach is less promising. Once you know the design and it
stabilized, then it is a good time to send it to sympy, so that it
becomes part of sympy and anybody can use it and build upon it.

Ondrej