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 <[email protected]> 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 > [email protected] || http://jrjohansson.github.io/research.html > >> On Nov 6, 2014, at 3:26 AM, nikolas <[email protected]> wrote: >> >> 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: >> • 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). >> • Add an adapted version of QNET's pattern matching facilties to a >> special (new? or existing) sympy module. >> • 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. >> • 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 >> >> >> >> On Tuesday, November 4, 2014 3:57:52 PM UTC-8, Aaron Meurer wrote: >> 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/268675B5-EF5E-45D9-97EF-E64C0FED3736%40gmail.com. For more options, visit https://groups.google.com/d/optout.
