I'd like to merge in this PR for a Trace object in MatrixExprs. Any objections? https://github.com/sympy/sympy/pull/1456
On Thu, Aug 2, 2012 at 8:40 AM, Matthew Rocklin <[email protected]> wrote: > 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.
