ecterrab

@peter137 How about this: ...

Answered: ecterrab 13431

March 28 2018

0 0

@peter137

How about this: straight and bold

>

(1)

>

(2)

It could also be not in bold ... but in bold seems more evident that this is not d(x). Regarding the alternative you suggested, within an integral is not a problem because you never enter the integration element itself, just the letter x, but outside an integral, for example to represent the differential of a coordinate, a case were you do input the object, I prefer to keep the distinction between a symbol and a function applied

One of the underlying issues regarding dx as the display of d(x) is the distinction, when using computer algebra, between a product and a function application, to the point that a lot of efforts were dedicated in Physics to implement products that work as function application (this new differentialoperators keyword in Setup, that one needs to intentionally invoke). To automatically hide this essential distinction between computing on paper and on a computer algebra worksheet seems to me, generally speaking, not really convenient, as a border not to be crossed.

Download d-ronde_or_d-straight_(II).mw

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

attaching the worksheet...

Answered: ecterrab 13431

March 27 2018

0 0

Hi Arny

It would be convenient if you attach the worksheet to your post to avoid copy & paste prone to mistakes - so, could you please post it? Thanks.

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

@Louis Lamarche You are confusing p...

Commented: ecterrab 13431

March 21 2018

@Louis Lamarche

You are confusing products of kets of one Hilbert space with tensor products of kets of different Hilbert spaces. You only have tensor products between objects belonging to different Hilbert spaces.

The reviewed version of your worksheet is attached at the end, and here are the notes I intercalated within your input/output lines:

To work with the right convention for the Dagger of a tensor product shown above you need to update your Physics library from the Maplesoft R&D Physics webpage.

Summarizing, Louis, in order to work with tensor products:

You need to indicate the (disjointed) Hilbert spaces of your problem and which operators act on each of these spaces
Be careful with the convention when taking Dagger.
Manually reordering Kets and Bras of a single Hilbert space, for which an inner product is already defined and therefore the operands in these products do not commute, is wrong, even if you happen to formulate the problem in a way that results in what you wanted to obtain. Helpful regarding such reorderings is the routine Physics:-Library:-Commute that receives A and B and tells you whether they commute.

Disjointedspaces_(reviewed).mw

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

@Louis Lamarche The Maplesoft R&...

Commented: ecterrab 13431

March 19 2018

@Louis Lamarche

The Maplesoft R&D Physics webpage distributes a Physics update for Maple 2017.3 that contains this new library mentioned in my comments to your post. From the worksheet you posted, I understand you are using Maple 2017, so this update should work for you, ie you can use it and test it.

Note three things anyway.

A relevant part of my previous comment is that what you show makes sense if and only if each of the kets a_j and b_k , totaling 8 kets, all of them belong to different Hilbert spaces. In your post you say that the a_j are the orthogonal kets of a single Hilbert space, that is not correct, and this is something not related to the dimension of the tensor product of spaces being n x m, not n + m.
In my previous comment, and in the Physics updated for Maple 2017 distributed at the Maplesoft R&D Physics webpage, I am using Dagger(Ket(A) x Ket(B)) = Bra(B) x Bra(A), where x here represents "tensor product". Although this is correct, because the Hilbert spaces A and B are disjointed, and Kets and Bras from the subspaces A and B commute. the notation used for tensor products that nevertheless preserves ordering, is: Dagger(Ket(A) x Ket(B)) = Bra(A) x Bra(B). This is known as the violation of the swapping rule of the Dagger operation and is the standard notation used for tensor products. The reason for this notation, particularly relevant in quantum information where the ket labels are not displayed, is that in states like |0, 1> and <0, 1|, you must preserve the ordering of the Hilbert subspaces, or otherwise, the notation is ambiguous. So, using the standard notation, if |0, 1> = |A, 0> x |B, 1>, then Dagger(|0, 1>) = <0, 1| = <A, 0|, <B, 1|, not <B, 1|, <A, 0|. As said this Maplesoft project is not finished and implementing this standard notation to represent the Dagger of a tensor product "violating the swapping rule" is still not in place.
By the way, the 'hide the ket label', is in place in the Physics update distributed for Maple 2017. Try Setup(hidketlabel = true), then enter Ket(A, 0) and you will see |0,> instead of |A, 0>. Remember anyway that you need to input the label A. The label is only hidden from the display.

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

@John Fredsted It is standard in co...

Answered: ecterrab 13431

March 17 2018

0 0

@John Fredsted

It is standard in computer algebra the concept of "special values", ie values for which you have the function evaluates automatically to something that is not just echoing your input unchanged. So for instance sin(-x) maps automatically into sin(x) and every single function, from BesselJ to AppellF1, will return in terms of some special values when the experience (subjective) with them tells it is better to return the special value. Of course some people would prefer to never evaluate any function to anything, but then, just my opinion, you would only get a nice text editor, not a math computing system.

So no, it would be non-sense to me to return Christoffel symbols for a Minkowski space, they are all equal to 0 (the special case were we do not want to go inert), and in the same line it would be just wrong to return zero for the Schwarzschild metric because they are not equal to zero.

Now on your manner of presenting this question, and I've seen this in several of your posts. You seem to ask things indirectly, parabolically. I prefer a more direct question. If your issue is that you want to work with an abstract tetrad, just ask that, and the answer to that is: no, we do not want to go that way because the resulting complexity of even simple algebraic computations can become enormous, making things rapidly untractable - instead of what we have today where you can compute in almost any imaginable scenario. My point here, however, is that instead of asking that, so that I could answer to that, with you I frequently go two to three rounds of answering this, then that, then this, then that, to finally discover that what you wanted to ask is actually something else, basically you seem to want to state that you would have designed this code differently. And to that I would just answer "all OK with that", instead of spending time answering questions that are not actually what you are interested on.

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

Comments and how to compute with "Tensor...

Commented: ecterrab 13431

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 13431

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 13431

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 13431

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 13431

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

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

13431 Reputation

24 Badges

MaplePrimes Activity

These are replies submitted by ecterrab

@peter137 How about this: ...

attaching the worksheet...

@Louis Lamarche You are confusing p...

@Louis Lamarche The Maplesoft R&...

@John Fredsted It is standard in co...

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...

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