Re: [sympy] Location for Tr operation

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 wrote: > Ah, I see, I would suggest that we call this the Kronecker product, not > Tensor product. In my mind tensor product me

Re: [sympy] Location for Tr operation

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 unfort

Re: [sympy] Location for Tr operation

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 wrote: > Can you define tensor product then? Are you referring to hadamard / > elementwise product? > > On Aug 1, 2012 6:02 PM, "Brian Granger" wrote:

Re: [sympy] Location for Tr operation

Can you define tensor product then? Are you referring to hadamard / elementwise product? On Aug 1, 2012 6:02 PM, "Brian Granger" wrote: > On Wed, Aug 1, 2012 at 1:55 PM, Matthew Rocklin > wrote: > > I'll reply more substantially in a bit (busy at work now) but I'll put > in a > > quick word now.

Re: [sympy] Location for Tr operation

On Wed, Aug 1, 2012 at 1:55 PM, Matthew Rocklin 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 c

Re: [sympy] Location for Tr operation

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. Matrix expressions would inherit a lot from tensor expressions but I still

Re: [sympy] Location for Tr operation

On Wed, Aug 1, 2012 at 11:02 AM, Matthew Rocklin wrote: > What about having a Trace(Expr) object, a PartialTrace(MatrixExpr) object > (which must be strictly a partial trace, not a full one, I.e. indices can > not equal all_indices) and a function that provides a general interface. That is a poss

Re: [sympy] Location for Tr operation

Matthew, On Wed, Aug 1, 2012 at 10:47 AM, Matthew Rocklin 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 operati

Re: [sympy] Location for Tr operation

What about having a Trace(Expr) object, a PartialTrace(MatrixExpr) object (which must be strictly a partial trace, not a full one, I.e. indices can not equal all_indices) and a function that provides a general interface. I would be much happier with this. I would still push for 1) _eval_trace belo

Re: [sympy] Location for Tr operation

I am still -1 on this. 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 Tra

Re: [sympy] Location for Tr operation

Guru, Thanks for summarizing things and making a recommendation. I agree with your proposal. On Wed, Aug 1, 2012 at 9:33 AM, Guru Devanla wrote: > I went through the entire thread again, I feel we should just move the > > 1. Tr module into matrices/expressions > 2. Decide between inheriting f

Re: [sympy] Location for Tr operation

I went through the entire thread again, I feel we should just move the 1. Tr module into matrices/expressions 2. Decide between inheriting from Expr or MatExpr. I would let it inherit from MatExpr, but set is_Matrix = false, if indices = all_indices. 3. And *not* have 2 classes, since except

Re: [sympy] Location for Tr operation

On Tue, Jul 31, 2012 at 4:55 PM, Guru Devanla wrote: > Based on the discussion so far, it seems that the opinion is current Tr > module should be moved to sympy/physics/quantum. Matt, per you suggestion do > you plan to add a simple Trace under MatrixExpressions, in that case? > > Also, can I leav

Re: [sympy] Location for Tr operation

Based on the discussion so far, it seems that the opinion is current Tr module should be moved to sympy/physics/quantum. Matt, per you suggestion do you plan to add a simple Trace under MatrixExpressions, in that case? Also, can I leave the name of the module the way it is now or should we chan

Re: [sympy] Location for Tr operation

> > Yes, the concept is quite subtle and not used (as far as I know) > outside the context of quantum mechanics (where it is used a lot). I > thought about having separate Trace and PartialTrace classes, but from > the user API standpoint, they are really the same thing. > > Trace = Partial Trace

Re: [sympy] Location for Tr operation

On Thu, Jul 12, 2012 at 2:19 PM, Matthew Rocklin wrote: > I had to look up partial trace (this is a new concept for me). After reading > this I'm inclined to separate Trace and PartialTrace classes in an effort to > optimize/simplify for the common case (at least the common case as I see > it). Y

Re: [sympy] Location for Tr operation

I had to look up partial trace (this is a new concept for me). After reading this I'm inclined to separate Trace and PartialTrace classes in an effort to optimize/simplify for the common case (at least the common case as I see it). The idea of a trace o

Re: [sympy] Location for Tr operation

One thing to be aware of is that the general Trace has to be able to handle partial traces of tensor products. This logic is implemented in this branch: https://github.com/sympy/sympy/pull/1396 And is somewhat specialized to the stuff in quantum, although it doesn't *depend* on quantum. Cheers,

Re: [sympy] Location for Tr operation

> > So do you think that the same object should trace over MatrixExpr, Matrix, > and the physics classes? It seems to me that it should. > Yes. I think that we can easily write a sufficiently general version of Trace, something like the Transpose object in this branch https://github.com/mrocklin/

Re: [sympy] Location for Tr operation

On Jul 12, 2012, at 10:26 AM, Matthew Rocklin wrote: I think that it makes sense to include a generic Trace object in matrix expressions. I think that it should inherit from Expr and not MatExpr (in my mind trace is a function :: Matrix -> Scalar). Guru, if you want a code example I would emulat

Re: [sympy] Location for Tr operation

I think that it makes sense to include a generic Trace object in matrix expressions. I think that it should inherit from Expr and not MatExpr (in my mind trace is a function :: Matrix -> Scalar). Guru, if you want a code example I would emulate the current Transpose object. I think that the Trace

Re: [sympy] Location for Tr operation

Aaron, Right now Tr class inherits from Expr directly. I will have to look into MatExpr as base class if that is necessary. -Guru On Wednesday, July 11, 2012 10:57:34 PM UTC-5, Aaron Meurer wrote: > > On Jul 11, 2012, at 9:45 PM, Guru Devanla wrote: > > Hello All, > > Recently I have been wor

Re: [sympy] Location for Tr operation

On Jul 11, 2012, at 9:45 PM, Guru Devanla wrote: Hello All, Recently I have been working on the Trace operator and related operations including partial traces. Currently, this operator is used exclusively by objects in the quantum module, though the operation itself is generic. Currently, this

[sympy] Location for Tr operation

Hello All, Recently I have been working on the Trace operator and related operations including partial traces. Currently, this operator is used exclusively by objects in the quantum module, though the operation itself is generic. Currently, this module resides in /sympy/core/trace.py There we