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. On Tue, Nov 4, 2014 at 3:49 PM, Ondřej Čertík <[email protected]> wrote: > 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. > 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 [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. > -- 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/CAKgW%3D6KZN4wpp32uMfQWSmzm2hQBWBEe%2Be-hQRHph1b2Sr2dNg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
