Hi Nikolas, On Tue, Nov 4, 2014 at 2:05 PM, nikolas <[email protected]> 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. > > 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. > > 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 > 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 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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. 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. For more options, visit https://groups.google.com/d/optout.
