ecterrab

Comments and how to compute with "Tensor...

Commented: ecterrab 14540

March 17 2018

I looked now at your presentation. Let me first say that it is nice for me to see how you use the Physics commands and types to develop your routine ExpandQop, related to "tensor products of two quantum operators in Dirac Notation". The topic is indeed relevant in general, more nowadays in the context of Quantum Information, and your initiative is more than welcome.

Three comments, however, spring to my mind.

1. You say

"Let A be an operator in a first Hilbert Space of dimension n, .... and B be an operator in a second Hilbert space of dimension m, . The tensor product of the two operators acts on a third Hilbert space ... "

The actual dimension of the Hilbert space conformed by the tensor product , however, is the product of the dimensions of and , not the sum of their dimensions, so is equal to , not to

2. A Hilbert space is a complex vector space with an inner product. Then there exists a complete basis of kets of that satisfy orthonormality,

with and The kets (states) of this basis act only within , with this inner product between themselves, and we do not form tensor products with these different states. The same holds for the kets (states) of the basis of .

On the other hand, within a tensor product of spaces , the kets of either or that are used to construct the basis of act transparently over the kets of the other subspace, and there is no inner product between a bra of one subspace and a ket of the other subspace.

Putting all together and using the notation you are using, if with belongs to and with belongs to then we have

So these three products form tensor products, while

So none of these three form a tensor product. I'm saying this because, in your post, after saying that the are the orthonormal (basis) kets of you show the image

as if one constructs tensor products multiplying the . The same applies to the orthonormal basis of that you represent using . In general, products of kets of the basis of only one Hilbert space do not form a tensor product of states even if you use different values of j.

Of course one could also ask about the tensor product of a Hilbert space with itself; yes you can talk about that, but then you do not have an inner product anymore: either (so no inner product, and then the subspace is not a Hilbert spaces) or (so no tensor products).

3. Your post, however, regains sense if we reinterpret your with as a set of Kets each of which belongs to a different Hilbert space (so they do not form an orthonormal basis of a single space as you say in your post)

With this reinterpretation, the results you show make sense. But then it is not the case that "Maple do not compute the tensor product of operators,"

What is true, however, is that the keyword for defining disjointed Hilbert spaces (each of which describes an independent system) is relatively new (only distributed with the Physics updates for Maple 2017) and is not explained in the documentation (my fault - the development planned is not finished, although the part related to tensor products mostly is).

The idea is that, to work with a Hilbert space, that is the tensor product of Hilbert subspaces, and where the states are formed taking the tensor product of states of each of the subspaces, you need a way to indicate to the system that the Hilbert subspaces are disjointed.

Being aware of this keyword, your computation is feasible, ther are also no restrictions to the number of subspaces (Your ExpandQop seems restricted to only two subspaces).

To see that, start defining the eight disjointed Hilbert spaces you use in your post

>

>	$Setup(hilbertspaces = {a__1, a__2, a__3, a__4, a__5, b__1, b__2, b__3})$

$[disjointedspaces = {{a__1}, {a__2}, {a__3}, {a__4}, {a__5}, {b__1}, {b__2}, {b__3}}]$

(1)

The output above reflects there are 8 disjointed spaces, each of which involves a single operator acting on it. Several things happen automatically after this input: these operators are automatically set to be quantum operators, and because they act on different disjointed spaces they automatically commute between themselves. For example:

>

(2)

>

(3)

Bras and Kets of one disjointed space act transparently over the bras and Kets of the other disjointed spaces, there is no inner product between states of one space and states of another (disjointed) one. For example:

>

(4)

Moving on the computation you show, you define (here I am basically copying from your worksheet and pasting)

>

(5)

>

(6)

>

(7)

>

(8)

At this point ,you say: "Maple do not compute the tensor product of operators,"

However,

>

(9)

Note this is precisely the result you obtain using your command ExpandQop. So it is not the case that Maple does not compute the tensor product.

Next you input

>

kets3 := kets1*kets2; bras3 := Dagger(kets3)

(10)

and compute the matrix element, saying:

However,

>

(11)

This result is also the same one you obtain using your command ExpandQop.

Next you shown this example

>

(12)

This result too is identical to the one you obtain using your command ExpandQop, and the same happens with the last two examples you show:

>

'F' = 'A*B/sqrt(2)+A*B/sqrt(2)'; F := A*B/sqrt(2)+A*B/sqrt(2); 'op(1, F)' = op(1, F); 'op(2, F)' = op(2, F)

op(1, F) = (1/2)*2^(1/2)*Physics:-`*`(Physics:-Ket(a__1), Physics:-Ket(a__2), Physics:-Ket(a__3), Physics:-Ket(a__4), Physics:-Ket(a__5), Physics:-Ket(b__1), Physics:-Ket(b__2), Physics:-Ket(b__3), Physics:-Bra(b__3), Physics:-Bra(b__2), Physics:-Bra(b__1), Physics:-Bra(a__5), Physics:-Bra(a__4), Physics:-Bra(a__3), Physics:-Bra(a__2), Physics:-Bra(a__1))

op(2, F) = (1/2)*2^(1/2)*Physics:-`*`(Physics:-Ket(b__1), Physics:-Ket(b__2), Physics:-Ket(b__3), Physics:-Ket(a__1), Physics:-Ket(a__2), Physics:-Ket(a__3), Physics:-Ket(a__4), Physics:-Ket(a__5), Physics:-Bra(a__5), Physics:-Bra(a__4), Physics:-Bra(a__3), Physics:-Bra(a__2), Physics:-Bra(a__1), Physics:-Bra(b__3), Physics:-Bra(b__2), Physics:-Bra(b__1))

(13)

and the one about multiple products

>

(14)

Here,, this output is actually a bit different that the one you show. For me, this one (14) is more clear: the brackets are explicit while in the output you show you have these products showing up, for instance, as where the contraction (inner product) is not actually performed, and the fact that these inner products (brackets) appear twice in the result (therefore, for instance, ) seems to be not detected by your program ExpandQop.

In summary of all this long reply:

1.	In your post, the dimension of the tensor product of spaces is not correct.

2.	The product of kets of one single Hilbert space do not form a tensor product (within one single space there is already an inner product handling products)

3.

Reinterpreting, in the excercise you posted, the kets and as belonging to different and disjointed Hilbert spaces the results you show, actually, are computed by Maple, depending on the case with some advantage, albeit using a keyword that is relatively new and not explained in the documentation yet.

Regarding 3. this development started in October/2017 in connection with an exchange with the Physics of Information Lab of the University of Waterloo - with them asking for a package about Quantum Information, for which it was necessary first to introduce the concept of disjointed Hilbert spaces and their related tensor products.

I will post here in Mapleprimes a description of all this functionality that already exists for "Tensor Products of Spaces" so that there is no confusion about this topic. Not having done that yet is by all means my fault.

Download Comments_to_your_ExpandQopV3_command.mw

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

Comments, and how to compute with "Tenso...

Commented: ecterrab 14540

March 16 2018

I looked now at your presentation. Let me first say that it is nice for me to see how you use the Physics commands and types to develop your routine ExpandQop, related to "tensor products of two quantum operators in Dirac Notation". The topic is indeed relevant in general, more nowadays in the context of Quantum Information, and your initiative is more than welcome.

Three comments, however, spring to my mind.

1. You say

"Let A be an operator in a first Hilbert Space of dimension n, .... and B be an operator in a second Hilbert space of dimension m, . The tensor product of the two operators acts on a third Hilbert space ... "

The actual dimension of the Hilbert space conformed by the tensor product , however, is the product of the dimensions of and , not the sum of their dimensions, so is equal to , not to

2. A Hilbert space is a complex vector space with an inner product. Then there exists a complete basis of kets of that satisfy orthonormality,

with and The kets (states) of this basis act only within , with this inner product between themselves, and we do not form tensor products with these different states. The same holds for the kets (states) of the basis of .

On the other hand, within a tensor product of spaces , the kets of either or that are used to construct the basis of act transparently over the kets of the other subspace, and there is no inner product between a bra of one subspace and a ket of the other subspace.

Putting all together and using the notation you are using, if with belongs to and with belongs to then we have

So these three products form tensor products, while

So none of these three form a tensor product. I'm saying this because, in your post, after saying that the are the orthonormal (basis) kets of you show the image

as if one constructs tensor products multiplying the . The same applies to the orthonormal basis of that you represent using . In general, products of kets of the basis of only one Hilbert space do not form a tensor product of states even if you use different values of j.

Of course one could also ask about the tensor product of a Hilbert space with itself; yes you can talk about that, but then you do not have an inner product anymore: either (so no inner product, and then the subspace is not a Hilbert spaces) or (so no tensor products).

3. Your post, however, regains sense if we reinterpret your with as a set of Kets each of which belongs to a different Hilbert space (so they do not form an orthonormal basis of a single space as you say in your post)

With this reinterpretation, the results you show make sense. But then it is not the case that "Maple do not compute the tensor product of operators,"

What is true, however, is that the keyword for defining disjointed Hilbert spaces (each of which describes an independent system) is relatively new (only distributed with the Physics updates for Maple 2017) and is not explained in the documentation (my fault - the development planned is not finished, although the part related to tensor products mostly is).

The idea is that, to work with a Hilbert space, that is the tensor product of Hilbert subspaces, and where the states are formed taking the tensor product of states of each of the subspaces, you need a way to indicate to the system that the Hilbert subspaces are disjointed.

Being aware of this keyword, your computation is feasible, ther are also no restrictions to the number of subspaces (Your ExpandQop seems restricted to only two subspaces).

To see that, start defining the eight disjointed Hilbert spaces you use in your post

>

>	$Setup(hilbertspaces = {a__1, a__2, a__3, a__4, a__5, b__1, b__2, b__3})$

$[disjointedspaces = {{a__1}, {a__2}, {a__3}, {a__4}, {a__5}, {b__1}, {b__2}, {b__3}}]$

(1)

The output above reflects there are 8 disjointed spaces, each of which involves a single operator acting on it. Several things happen automatically after this input: these operators are automatically set to be quantum operators, and because they act on different disjointed spaces they automatically commute between themselves. For example:

>

(2)

>

(3)

Bras and Kets of one disjointed space act transparently over the bras and Kets of the other disjointed spaces, there is no inner product between states of one space and states of another (disjointed) one. For example:

>

(4)

Moving on the computation you show, you define (here I am basically copying from your worksheet and pasting)

>

(5)

>

(6)

>

(7)

>

(8)

At this point ,you say: "Maple do not compute the tensor product of operators,"

However,

>

(9)

Note this is precisely the result you obtain using your command ExpandQop. So it is not the case that Maple does not compute the tensor product.

Next you input

>

kets3 := kets1*kets2; bras3 := Dagger(kets3)

(10)

and compute the matrix element, saying:

However,

>

(11)

This result is also the same one you obtain using your command ExpandQop.

Next you shown this example

>

(12)

This result too is identical to the one you obtain using your command ExpandQop, and the same happens with the last two examples you show:

>

'F' = 'A*B/sqrt(2)+A*B/sqrt(2)'; F := A*B/sqrt(2)+A*B/sqrt(2); 'op(1, F)' = op(1, F); 'op(2, F)' = op(2, F)

op(1, F) = (1/2)*2^(1/2)*Physics:-`*`(Physics:-Ket(a__1), Physics:-Ket(a__2), Physics:-Ket(a__3), Physics:-Ket(a__4), Physics:-Ket(a__5), Physics:-Ket(b__1), Physics:-Ket(b__2), Physics:-Ket(b__3), Physics:-Bra(b__3), Physics:-Bra(b__2), Physics:-Bra(b__1), Physics:-Bra(a__5), Physics:-Bra(a__4), Physics:-Bra(a__3), Physics:-Bra(a__2), Physics:-Bra(a__1))

op(2, F) = (1/2)*2^(1/2)*Physics:-`*`(Physics:-Ket(b__1), Physics:-Ket(b__2), Physics:-Ket(b__3), Physics:-Ket(a__1), Physics:-Ket(a__2), Physics:-Ket(a__3), Physics:-Ket(a__4), Physics:-Ket(a__5), Physics:-Bra(a__5), Physics:-Bra(a__4), Physics:-Bra(a__3), Physics:-Bra(a__2), Physics:-Bra(a__1), Physics:-Bra(b__3), Physics:-Bra(b__2), Physics:-Bra(b__1))

(13)

and the one about multiple products

>

(14)

Here,, this output is actually a bit different that the one you show. For me, this one (14) is more clear: the brackets are explicit while in the output you show you have these products showing up, for instance, as where the contraction (inner product) is not actually performed, and the fact that these inner products (brackets) appear twice in the result (therefore, for instance, ) seems to be not detected by your program ExpandQop.

In summary of all this long reply:

1.	In your post, the dimension of the tensor product of spaces is not correct.

2.	The product of kets of one single Hilbert space do not form a tensor product (within one single space there is already an inner product handling products)

3.

Reinterpreting, in the excercise you posted, the kets and as belonging to different and disjointed Hilbert spaces the results you show, actually, are computed by Maple, depending on the case with some advantage, albeit using a keyword that is relatively new and not explained in the documentation yet.

Regarding 3. this development started in October/2017 in connection with an exchange with the Physics of Information Lab of the University of Waterloo - with them asking for a package about Quantum Information, for which it was necessary first to introduce the concept of disjointed Hilbert spaces and their related tensor products.

I will post here in Mapleprimes a description of all this functionality that already exists for "Tensor Products of Spaces" so that there is no confusion about this topic. Not having done that yet is by all means my fault.

Download Comments_to_your_ExpandQopV3_command.mw

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

Answered: ecterrab 14540

February 01 2018

0 0

@trace

You asked for an expansion removing higher order terms in g(r), a well defined thing. You didn't ask fo an expression smaller than something, which by the way is not a well defined thing. I only showed you what you asked, it seems easy, just use the series command, frontended to workaround the fact that the expansion variable is a function, and that is all.

As for size, did you give a look a (17) you are expanding? it has a denominator of degree 4 in g(r). Then, You will not just get something smaller, or what where you expecting in an expansion in such a case?

(17) is of the form

ee := f(x)*(1/(a*(x^4)+b*(x^3)+c*(x^2)+d));
                                 f(x)         
                  ee := ----------------------
                           4      3      2    
                        a x  + b x  + c x  + d
series(ee, x, 2);
                    f(0)   D(f)(0)      / 2\
                    ---- + ------- x + O\x /
                     d        d

Anyway I'm sorry I cannot help you more in this thread.

Best

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@trace In a previous comment of y...

Answered: ecterrab 14540

February 01 2018

0 0

@trace

In a previous comment of yours, here above, you asked "how can i eliminate non-linear terms like g(r)^2 from 17". That is what I showed replying you: frontend(series, [(17), g(r), 2]). Now you jumped to another branch. So not g(r). H(r) instead. I will give a look later today or in a couple of days - I'm rather busy in this moment.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@trace In your JJ.mw, you compute...

Answered: ecterrab 14540

February 01 2018

0 0

@trace

In your JJ.mw, you computed a series with respect to H(r), not g(r). Concretely, I read frontend(series, [(17), H(r), 2]), not frontend(series, [(17), g(r), 2]). If you compute the series w.r.t g(r) - this is what you asked - you do get a result. By the way, please read ?series: you can afterwards check the degree using 'degree', and also convert(..., polynom) if desired, to remove the 'series' computational structure and the O(g(r)^2) term.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@trace To Define k_[mu,nu] indica...

Answered: ecterrab 14540

January 31 2018

0 0

@trace

To Define k_[mu,nu] indicating its components, please do as you did for N[mu] and F[mu,nu] in Plugging in a metric ansatz, thread that you also started. If that does not resolve your problem, please let me see what you are doing to define k_[mu,nu] indicating its components and that does not work, thanks.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

series...

Answered: ecterrab 14540

January 31 2018

0 0

@trace

To discard terms of degree greater than one in g(r) use series. That command however does not accept a second argument of type function (g(r)), so use it with frontend, as in

> frontend(series, [(17), g(r), 2])

Regarding "how can i put k components" I do not understand what you mean by that - an example? Do you mean assigning values to the components of k? If so it suffices to define k (using Define) indicating its components, instead of just Define(k_[mu,nu], symmetric) as I did in the review of your worksheet, or otherwise leave that definition as it is and redefine k_ indicating its components just before (or even after) using series to discard terms O(g(r)^2).

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@Rouben Rostamian As is clear from ...

Answered: ecterrab 14540

January 22 2018

0 0

@Rouben Rostamian

As is clear from the previous replies, although I understand you think abs(x) in this context is bogus, I think it is not. However, taking as reference the previous comments, the solution with x instead of abs(x) is definitely simpler, and the introduction of complex components (abs, csgn signum) when simplifying solutions to linear equations is a pattern that can be checked at a low cost, identify the radicals that lead to these complex components through simplification, take advantage of integration contants to reabsorb constant factors, and in this way rewrite the solution in simpler form. Depending on the program, to do this kind of manipulation may be tricky, but not in this case, the symmetry routines in Maple are pretty modern code.

I implemented this change (you can install it by updating your Maple 2017.3 with the update for Physics, Differential Equations and Mathematical functions distributed at the Maplesoft R&D Physics webpage), and now we receive the one you were expecting, that I call the simpler solution:

Download solution_without_abs.mw

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@Rouben Rostamian A constant doe...

Answered: ecterrab 14540

January 16 2018

0 0

@Rouben Rostamian

A constant doesn't need to be continuous; a piecewise constant is valid; you see however that the problem is at its discontinuity, the origin, exactly where signum(1, x) is undefined. All I am saying (have been saying) is that the solution returned for the symbolic problem without initial/boundary conditions is correct except at one point, that arbitrary constants can be piecwise constants (but for their value at that point) and that the problem of all this is in the simplifier when it changes the solution computed by the PDE symmetry routines introducing abs. That introduction is not OK but the consequence, for x::real, is only to make the solution not valid at the origin.

Anyway, arguments went back and forth, I enjoyed the exchange, but need to return to other matters.

Best

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@Rouben Rostamian Hold on: the p...

Answered: ecterrab 14540

January 16 2018

0 0

@Rouben Rostamian

Hold on: the problem posted has no initial conditions, leaving a lot of freedom in the choice of the arbitrary constants _C1 and _C2 to overcome almost any argumentation. On the other hand, the example you are presenting as argument has initial conditions. With (please!) no offense, I think you cannot compare one thing with the other one. More concretely, look at the solution, with the term under focus of the form _C2*erf(abs(x)) where x::real. You know erf(-x) = -erf(x); reabsorb now that sign within _C2 and you can even say that for x >= 0 you have _C2*erf(abs(x)) = _C2*erf(x) while for x < 0 you have _C3*erf(x), and there you are, watching at a solution arguably valid all around x::real.

The key observation here is that a problem without initial conditions has some extra freedom that a problem with initial conditions (provided it is well defined) has not.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

E-Mail Address:
Password:
Remember Me:	Automatically sign in on future visits

E-Mail Address:
Password:
Remember Me:	Automatically sign in on future visits

Ask a Question

Create a Post

14540 Reputation

24 Badges

MaplePrimes Activity

These are replies submitted by ecterrab

Comments and how to compute with "Tensor...

Comments, and how to compute with "Tenso...

@John Fredsted Don't know wha...

@max125 The dsolve command, as well...

@tomleslie I understand that proble...

@tomleslie I have no idea why the l...

Physics...

@trace You asked for an expansion...

@trace In a previous comment of y...

@trace In your JJ.mw, you compute...

@trace To Define k_[mu,nu] indica...

series...

@Rouben Rostamian As is clear from ...

@Rouben Rostamian A constant doe...

@Rouben Rostamian Hold on: the p...

Save this setting as your default sorting preference?

Ask a Question

Create a Post

Generating PDF…

Save this setting as your default sorting preference?
Note: You can change your preference any time in your account settings
Don't show this again