Ah, I see, I would suggest that we call this the Kronecker product, not Tensor product. In my mind tensor product means this http://en.wikipedia.org/wiki/Tensor_product and more specifically this http://en.wikipedia.org/wiki/Tensor_product#Tensor_product_of_two_tensors but the term tensor is unfortunately overloaded.
To me, Kronecker product, partial trace, etc... are all very obscure functionality. This is probably because I think about numerical linear algebra rather than quantum mechanics and because I am unfamiliar with them. My perspective is skewed. I am not in general opposed to anything joining MatrixExprs. I am opposed to these things causing what I think of as the MatrixExpr core to become more complex. I believe that this tension is relieved by having many atomic classes rather than a few swiss-army-knife classes. I ascribe fairly strongly to the idea that two simple classes are better than one complex class. Regarding the broader issue sympy/physics/quantum works very differently from MatrixExpr - at least that was the impression I gained when I studied it while building MatrixExprs. Quantum builds itself off of the SymPy core objects (i.e. Symbol, Expr) while MatrixExpr created new core objects (MatrixSymbol, MatrixExpr). I suspect that an attempt to glom together the two systems will result in tension. I care strongly about the core of MatrixExprs and have thoughts about exactly what it should look like and how it should grow. I do not however own MatrixExprs and, as far as I can tell, I'm currently the only user. So if it should evolve away from my vision of it (which looks like this<https://github.com/mrocklin/matrix-algebra>) then that's ok. I'll probably work on it much less, but that's ok too. If you're actually thinking of re-implementing everything in MatrixExprs then my proposed solution is to have a MatrixExpr core and have separate MatrixExpr modules. I would put PartialTrace into a module and once it proves useful for other MatrixExpr tasks we merge it into the core. If we wanted to merge Quantum and MatrixExprs I think this would also be a good approach. This is likely a lot of work though. It is however, I think, a good idea in the long run. There is work that I have planned for MatrixExprs (like an assumptions system) that I suspect could benefit quantum. The idea of PR1158 was to put a hermitian assumption into the SymPy core assumptions system. I think this sort of addition belongs in a new assumptions system for MatrixExprs. One that looks and operates much like this<https://github.com/mrocklin/matrix-algebra/blob/master/src/assumptions.maude> . On Wed, Aug 1, 2012 at 6:31 PM, Brian Granger <[email protected]> wrote: > For matrices it looks like this: > > http://en.wikipedia.org/wiki/Kronecker_product > > Cheers, > > Brian > > On Wed, Aug 1, 2012 at 4:26 PM, Matthew Rocklin <[email protected]> > wrote: > > Can you define tensor product then? Are you referring to hadamard / > > elementwise product? > > > > On Aug 1, 2012 6:02 PM, "Brian Granger" <[email protected]> wrote: > >> > >> On Wed, Aug 1, 2012 at 1:55 PM, Matthew Rocklin <[email protected]> > >> wrote: > >> > I'll reply more substantially in a bit (busy at work now) but I'll put > >> > in a > >> > quick word now. > >> > > >> > I think that an optimal version of SymPy would have a dedicated tensor > >> > module. I think that MatrixExpr would subclass TensorExpr. > >> > >> I should clarify something. The tensor product of matrices is itself > >> a matrix, not a higher dimensional tensor. By TensorExpr, I think you > >> are referring to something more general = a full blown tensor with > >> rank potentially > 2. Those types of tensors are not in any way > >> relevant in quantum mechanics. > >> > >> > Matrix expressions would inherit a lot from tensor expressions but I > >> > still > >> > think that they would need to be part of a separate submodule. Linear > >> > algebra has been developed much more than multilinear algebra and > there > >> > are > >> > some thoughts and many use-cases that don't generalize. > >> > >> Again, multilinear algebra is not relevant here, just plain old linear > >> algebra. > >> > >> > I don't think that MatrixExprs should be generalized to TensorExprs. I > >> > think > >> > that TensorExprs should be created and then code from MatrixExprs > >> > factored > >> > out. > >> > >> I think this vision of having TensorExpr and MatrixExpr does make > >> sense, but again, the types of operations under discussion here are > >> under the matrix/linear algebra category. > >> > >> > (I haven't mentioned anything here about the Tensor vs NDArray > >> > discussion, > >> > which is also relevant but complicates this idea) > >> > > >> > I'll take a look at your PR. Thanks for bringing it to my attention :) > >> > > >> > On Wed, Aug 1, 2012 at 2:23 PM, Brian Granger <[email protected]> > >> > wrote: > >> >> > >> >> Matthew, > >> >> > >> >> On Wed, Aug 1, 2012 at 10:47 AM, Matthew Rocklin <[email protected] > > > >> >> wrote: > >> >> > I am still -1 on this. > >> >> > >> >> There is a larger discussion lurking here though. Right now, the > >> >> vision of matrix expressions leaves out a huge class of operation > >> >> involving matrices, namely those related to tensor products. Many > >> >> operations on matrices naturally extend to tensor products of > matrices > >> >> and all of these things also extend to linear operators on Hilbert > >> >> spaces. Other examples of things that can be defined on tensor > >> >> products of matrices: Transpose, Adjoint. All of these operations > >> >> have a similar API as Trace/Partial trace in that you can do the > >> >> operation on all matrices in a tensor product, or just some of them > >> >> (the "partial" version). I agree these operations are not common > >> >> outside of quantum mechanics, but tensor products are a mainstream > >> >> part of linear algebra. > >> >> > >> >> Are you open to the matrix expression modules gaining knowledge of > >> >> tensor products? If not, we are going to have to reimplement > >> >> everything in both matrix expressions and outside of it. BTW, we are > >> >> already going in this direction, in the sense that we have a PR open > >> >> #1158 for transpose/adjoint classes in > >> >> sympy/functions/elementary/complexes.py. The quantum module is using > >> >> those. Maybe this is the direction we need to go. In that case, why > >> >> not put Trace in the same place as transpose/adjoint, as they are > very > >> >> similar. > >> >> > >> >> > I have no problem to an unevaluated PartialTrace object living in > >> >> > matrix/expressions. I just think that it should be separate. > >> >> > > >> >> > Here are some of my concerns. > >> >> > > >> >> > From a user perspective having two separate classes is simpler in > >> >> > expectation. 99% of the time a user will want Trace. These users > >> >> > should > >> >> > not > >> >> > have to deal with the complexity of PartialTrace. I.e. the > docstring > >> >> > for > >> >> > Trace should be very simple and intuitive. PartialTrace is foreign > to > >> >> > most > >> >> > users. > >> >> > >> >> Unless a user is doing quantum mechanics, then they will want partial > >> >> traces a good fraction of the time. I am still thinking about having > >> >> separate trace and partial trace operations, but I want to come up > >> >> with a unified way of handling these partial operations (for > >> >> transpose/adjoint) as well. Not sure it makes sense to have partial > >> >> transpose/adjoint as well. I am still leaning towards having a > single > >> >> object, but am considering the 2 object option as well. > >> >> > >> >> > Trace is a scalar, PartialTrace can be a Matrix. The type system in > >> >> > the > >> >> > MatrixExpr module is much stricter than in physics/quantum. There > is > >> >> > no > >> >> > way > >> >> > to have an object that is both. All MatrixExpr's have a shape. What > >> >> > is > >> >> > the > >> >> > shape of Trace(X)? If it is 1x1 then it will not be able to > interact > >> >> > with > >> >> > other MatrixExprs. The MatrixExpr module is very clean and simple > >> >> > right > >> >> > now. > >> >> > I will strongly object to any type magic. The module is currently > >> >> > very > >> >> > simple, I would really like to keep it this way. > >> >> > >> >> I can see how this would be useful in matrix expressions if you don't > >> >> ever plan on generalizing things to include tensor products. If you > >> >> do though, these things will come up. > >> >> > >> >> > I think that having two simple classes is far simpler than having > one > >> >> > complex class that can be many things. > >> >> > >> >> But it is not really that complex and it is not "many" things, just > two > >> >> at > >> >> most. > >> >> > >> >> > Here is a PR for simple Trace. It is on top of another PR so only > the > >> >> > last > >> >> > two commits are relevant to this conversation > >> >> > https://github.com/sympy/sympy/pull/1456 > >> >> > >> >> I guess the larger question is how you see matrix expressions > >> >> co-existing with the rest of sympy. Is the stuff in matrix > >> >> expressions so specialized that it is justified to have its own > >> >> implementations of everything like trace/transpose/adjoint? > >> >> > >> >> Cheers, > >> >> > >> >> Brian > >> >> > >> >> > -- > >> >> > You received this message because you are subscribed to the Google > >> >> > Groups > >> >> > "sympy" group. > >> >> > To post to this group, send email to [email protected]. > >> >> > To unsubscribe from this group, send email to > >> >> > [email protected]. > >> >> > For more options, visit this group at > >> >> > http://groups.google.com/group/sympy?hl=en. > >> >> > >> >> > >> >> > >> >> -- > >> >> Brian E. Granger > >> >> Cal Poly State University, San Luis Obispo > >> >> [email protected] and [email protected] > >> >> > >> >> -- > >> >> You received this message because you are subscribed to the Google > >> >> Groups > >> >> "sympy" group. > >> >> To post to this group, send email to [email protected]. > >> >> To unsubscribe from this group, send email to > >> >> [email protected]. > >> >> For more options, visit this group at > >> >> http://groups.google.com/group/sympy?hl=en. > >> >> > >> > > >> > -- > >> > You received this message because you are subscribed to the Google > >> > Groups > >> > "sympy" group. > >> > To post to this group, send email to [email protected]. > >> > To unsubscribe from this group, send email to > >> > [email protected]. > >> > For more options, visit this group at > >> > http://groups.google.com/group/sympy?hl=en. > >> > >> > >> > >> -- > >> Brian E. Granger > >> Cal Poly State University, San Luis Obispo > >> [email protected] and [email protected] > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "sympy" group. > >> To post to this group, send email to [email protected]. > >> To unsubscribe from this group, send email to > >> [email protected]. > >> For more options, visit this group at > >> http://groups.google.com/group/sympy?hl=en. > >> > > -- > > You received this message because you are subscribed to the Google Groups > > "sympy" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group at > > http://groups.google.com/group/sympy?hl=en. > > > > -- > Brian E. Granger > Cal Poly State University, San Luis Obispo > [email protected] and [email protected] > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. > > -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
