ecterrab

14205 Reputation

24 Badges

19 years, 219 days

MaplePrimes Activity


These are answers submitted by ecterrab

A new Physics:-Library:-Add command is included in today's update of Physics, implementing the ideas discussed in this post, so working around the model of evaluation of arguments of sum that sometimes generates unexpected results as discussed for instance in the Mapleprimes posts of August  annihilation/creation operators , Problem-With-A-Function-Within-Sum, and Sum-In-For-Loop. The next upated by the end of the week will include a `print/Add` to have the expected capital Sigma display an related copy & paste.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Andriy 


You posted 3 replies. Let me go through them in sequence in a single reply here, and in what follows I am using the next update of Physics, to be posted tomorrow:

restart; with(Physics); Physics:-Version()

"/Users/ecterrab/Maple/lib/Physics.mla", `2013, September 16, 16:33 hours`

(1)

____________________________________

 

In your 'Great but not perfect', the problem is not in SortProducts but in AntiCommutator. You know, for Commutators you can always expand them when one of the operands is a product, say as in,

Setup(quantumoperators = {A, B, C, F, G})

Commutator(A*B, C)

Physics:-`*`(A, Physics:-Commutator(B, C))+Physics:-`*`(Physics:-Commutator(A, C), B)

(2)

But this formula does not exist for anticommutators, so anticommutators of products are not expanded

AntiCommutator(A*B, C)

Physics:-AntiCommutator(Physics:-`*`(A, B), C)

(3)

On the other hand - say in this example - if the anticommutator between B and C and also between A and C are known, then one can always compute this anticommutator as an expansion.


Example:

Setup(%AntiCommutator(A, C) = F, %AntiCommutator(B, C) = G)

[algebrarules = {%AntiCommutator(A, C) = F, %AntiCommutator(B, C) = G}]

(4)

The following anticommutator returns uncomputed with the version of Physics you have, but from the knowlege of the anticommutatores (rules) above it can always be computed:

AntiCommutator(A*B, C)

2*Physics:-`*`(C, A, B)+Physics:-`*`(A, G)-Physics:-`*`(F, B)

(5)

In steps:

%AntiCommutator(A*B, C); % = expand(%)

%AntiCommutator(Physics:-`*`(A, B), C) = Physics:-`*`(A, B, C)+Physics:-`*`(C, A, B)

(6)

Take the first term on the right-hand side and move C to the left in two steps: first anticommuting with C with B then with A.

Step 1

%AntiCommutator(B, C); % = expand(%)

%AntiCommutator(B, C) = Physics:-`*`(B, C)+Physics:-`*`(C, B)

(7)

isolate(%, B*C)

Physics:-`*`(B, C) = %AntiCommutator(B, C)-Physics:-`*`(C, B)

(8)

value(%)

Physics:-`*`(B, C) = G-Physics:-`*`(C, B)

(9)

A*lhs(%) = map2(`*`, A, rhs(%))

Physics:-`*`(A, B, C) = Physics:-`*`(A, G)-Physics:-`*`(A, C, B)

(10)

subs(%, %AntiCommutator(Physics[`*`](A, B), C) = Physics[`*`](A, B, C)+Physics[`*`](C, A, B))

%AntiCommutator(Physics:-`*`(A, B), C) = Physics:-`*`(A, G)-Physics:-`*`(A, C, B)+Physics:-`*`(C, A, B)

(11)

Step 2

%AntiCommutator(A, C); % = expand(%)

%AntiCommutator(A, C) = Physics:-`*`(A, C)+Physics:-`*`(C, A)

(12)

isolate(%, A*C)

Physics:-`*`(A, C) = %AntiCommutator(A, C)-Physics:-`*`(C, A)

(13)

value(%)

Physics:-`*`(A, C) = F-Physics:-`*`(C, A)

(14)

lhs(%)*B = map(`*`, rhs(%), B)

Physics:-`*`(A, C, B) = Physics:-`*`(F, B)-Physics:-`*`(C, A, B)

(15)

subs(%, %AntiCommutator(Physics[`*`](A, B), C) = Physics[`*`](A, G)-Physics[`*`](A, C, B)+Physics[`*`](C, A, B))

%AntiCommutator(Physics:-`*`(A, B), C) = 2*Physics:-`*`(C, A, B)+Physics:-`*`(A, G)-Physics:-`*`(F, B)

(16)

This mechanism to compute the anticommutator of products when the anticommutator for each of the operands of the product is known was not implemented, and so SortProducts was returning with an AntiCommutator uncomputed. After implementing this, for the example you posted in "Great but not perfect" we now have

Setup(anticommutativeprefix = psi)

[anticommutativeprefix = {_lambda, psi}]

(17)

for i to 4 do ap[i] := Creation(psi, i, notation = explicit); am[i] := Annihilation(psi, i, notation = explicit) end do

ee := ap[2].am[2].am[1].ap[1]

Physics:-`.`(`a+`[psi[2]], Physics:-`.`(`a-`[psi[2]], Physics:-`.`(`a-`[psi[1]], `a+`[psi[1]])))

(18)

ApAm1 := [seq(ap[j], j = 1 .. 4), seq(am[j], j = 1 .. 4)]

[`a+`[psi[1]], `a+`[psi[2]], `a+`[psi[3]], `a+`[psi[4]], `a-`[psi[1]], `a-`[psi[2]], `a-`[psi[3]], `a-`[psi[4]]]

(19)

No uncomputed anticommutators:

Library:-SortProducts(ee, ApAm1, useanticommutator)

Physics:-`.`(`a+`[psi[1]], `a+`[psi[2]], `a-`[psi[1]], `a-`[psi[2]])+Physics:-`.`(`a+`[psi[2]], `a-`[psi[2]])

(20)

____________________________________

 

In your next reply "Another issue appeared", you point out that simplify/size does not collect the terms the way you want and is expected.

Setup(clear, op = C, quiet)

[quantumoperators = {A, B, F, G}]

(21)

z2 := 3*ap[1].am[1]+R*ap[1].am[1]+K*(ap[2].am[2])/(C+D)

3*Physics:-`.`(`a+`[psi[1]], `a-`[psi[1]])+R*Physics:-`.`(`a+`[psi[1]], `a-`[psi[1]])+K*Physics:-`.`(`a+`[psi[2]], `a-`[psi[2]])/(C+D)

(22)

simplify(z2, size)

3*Physics:-`.`(`a+`[psi[1]], `a-`[psi[1]])+R*Physics:-`.`(`a+`[psi[1]], `a-`[psi[1]])+K*Physics:-`.`(`a+`[psi[2]], `a-`[psi[2]])/(C+D)

(23)

Note three things.

1) This result is not collected as we expect, but it is not wrong as you say.

2) The problem is not related to Physics.

 

For example, remove all Physics objects

subs(am[1] = am1, ap[1] = ap1, am[2] = am2, ap[2] = ap2, `.` = :-`*`, %)

3*(ap1*am1)+R*(ap1*am1)+K*(ap2*am2)/(C+D)

(24)

Try again and you see the same situation, the expression is not reduced in size

simplify(%, size)

3*ap1*am1+R*ap1*am1+K*ap2*am2/(C+D)

(25)

3) You can achieve what you want with the expression z2 directly using collect, as in

collect(z2, `.`)

(R+3)*Physics:-`.`(`a+`[psi[1]], `a-`[psi[1]])+K*Physics:-`.`(`a+`[psi[2]], `a-`[psi[2]])/(C+D)

(26)

____________________________________

 

In your third and last reply, "The coefficients of operator expression", you show that Coefficients is not working as expected. Indeed it takes coefficients in noncommutative products expressed using Physics:-`*`, not Physics:-`.`. This is explained in the help page.


On the other hand I agree with you, Coefficients should work with both Physics:-`*` and Physics:-`.` in equal footing. This is implemented now (to appear tomorrow), so that we get

Coefficients(z2, ap[1])

K*Physics:-`.`(`a+`[psi[2]], `a-`[psi[2]])/(C+D), (R+3)*`a-`[psi[1]]

(27)

Coefficients(z2, ap[1], 0)

K*Physics:-`.`(`a+`[psi[2]], `a-`[psi[2]])/(C+D)

(28)

It works also with a product as second argument, as in:

Coefficients(z2, [ap[1].am[1]], 1)

R+3

(29)

Coefficients(z2, [ap[1].am[1]], 0)

K*Physics:-`.`(`a+`[psi[2]], `a-`[psi[2]])/(C+D)

(30)

Coefficients(z2, [ap[1].am[1]])

K*Physics:-`.`(`a+`[psi[2]], `a-`[psi[2]])/(C+D), R+3

(31)

The key here was adapting Library:-Degree to work withPhysics:-`*` and Physics:-`.` in equal footing, and with that we got Coefficients working as expected:

Library:-Degree(z2, ap[2], minmax = both)

0, 1

(32)

Library:-Degree(z2, [ap[2], am[2]], minmax = both)

0, 2

(33)

Library:-Degree(z2, [ap[2].am[2]], minmax = both)

0, 1

(34)

In summary for your three replies: 1) AntiCommutator got improved (that resolved your issue with SortProducts), 2) use collect (simplify/size works very well but in this example requires a tweak and I am short of time to fix that); 3) Library:-Degree, and through it also Coefficients now work with Physics:-`.` the same way they do with Physics:-`*`.

 

All these changes and some others as a new Library:-Add and Library:-TensorCoefficients are already included in the update being prepared for tomorrow. Regarding Library:-Collect, yes it is part of the plan, but other things are a bit higher in the priority list (e.g. Hausorff's formula, relevant in basic QM). Anyway, at some point soon enough Collect will be in place together with a new Factor handling noncommutative products.

NULL



Download MaplePrimesSortProducts.mw

 

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Andriy 

Today's update got posted in the usual Maplesoft Physics Updates webpage the problem you noticed got fixed, some other things got improved and new stuff added in connection with feedback by other people. Altogether, we now have: 

restart; with(Physics); with(Library); Physics:-Version()

"/Users/ecterrab/Maple/lib/Physics.mla", `2013, September 13, 12:27 hours`

(1)

Setup(mathematicalnotation = true, anticommutativeprefix = psi)

[anticommutativeprefix = {_lambda, psi}, mathematicalnotation = true]

(2)

for i to 4 do ap[i] := Creation(psi, i, notation = explicit); am[i] := Annihilation(psi, i, notation = explicit) end do:

 

Consider the expression z and the ordering ApAm1

z := Typesetting:-delayDotProduct(Typesetting:-delayDotProduct(Typesetting:-delayDotProduct(Physics:-`*`(A, ap[2]), am[2]), ap[1]), am[1])+Typesetting:-delayDotProduct(Typesetting:-delayDotProduct(Typesetting:-delayDotProduct(Physics:-`*`(B, ap[1]), am[1]), ap[2]), am[2])+Typesetting:-delayDotProduct(Typesetting:-delayDotProduct(Typesetting:-delayDotProduct(Physics:-`*`(C, ap[3]), am[3]), ap[4]), am[4])

A*Physics:-`.`(`a+`[psi[2]], Physics:-`.`(`a-`[psi[2]], Physics:-`.`(`a+`[psi[1]], `a-`[psi[1]])))+B*Physics:-`.`(`a+`[psi[1]], Physics:-`.`(`a-`[psi[1]], Physics:-`.`(`a+`[psi[2]], `a-`[psi[2]])))+C*Physics:-`.`(`a+`[psi[3]], Physics:-`.`(`a-`[psi[3]], Physics:-`.`(`a+`[psi[4]], `a-`[psi[4]])))

(3)

ApAm1 := [seq(ap[j], j = 1 .. 4), seq(am[j], j = 1 .. 4)]

[`a+`[psi[1]], `a+`[psi[2]], `a+`[psi[3]], `a+`[psi[4]], `a-`[psi[1]], `a-`[psi[2]], `a-`[psi[3]], `a-`[psi[4]]]

(4)

Compare the behavior with and without the evaluateexpression optional argument

SortProducts(z, ApAm1, useanticommutator)

-A*Physics:-`.`(`a+`[psi[1]], `a+`[psi[2]], `a-`[psi[1]], `a-`[psi[2]])-B*Physics:-`.`(`a+`[psi[1]], `a+`[psi[2]], `a-`[psi[1]], `a-`[psi[2]])-C*Physics:-`.`(`a+`[psi[3]], `a+`[psi[4]], `a-`[psi[3]], `a-`[psi[4]])

(5)

SortProducts(z, ApAm1, useanticommutator, evaluateexpression)

-A*Physics:-`.`(`a+`[psi[1]], Physics:-`.`(`a+`[psi[2]], Physics:-`.`(`a-`[psi[1]], `a-`[psi[2]])))-B*Physics:-`.`(`a+`[psi[1]], Physics:-`.`(`a+`[psi[2]], Physics:-`.`(`a-`[psi[1]], `a-`[psi[2]])))-C*Physics:-`.`(`a+`[psi[3]], Physics:-`.`(`a+`[psi[4]], Physics:-`.`(`a-`[psi[3]], `a-`[psi[4]])))

(6)

Sorting using commutator leads to the same result

SortProducts(z, ApAm1, usecommutator, evaluateexpression)

-A*Physics:-`.`(`a+`[psi[1]], Physics:-`.`(`a+`[psi[2]], Physics:-`.`(`a-`[psi[1]], `a-`[psi[2]])))-B*Physics:-`.`(`a+`[psi[1]], Physics:-`.`(`a+`[psi[2]], Physics:-`.`(`a-`[psi[1]], `a-`[psi[2]])))-C*Physics:-`.`(`a+`[psi[3]], Physics:-`.`(`a+`[psi[4]], Physics:-`.`(`a-`[psi[3]], `a-`[psi[4]])))

(7)

evalb(`%%` = %)

true

(8)

Regarding another question you made, to factor out common factors, this output by SortProducts as well as all the output of Physics commands can be handled via simplify/size

simplify(`%%`, size)

(-A-B)*Physics:-`.`(`a+`[psi[1]], Physics:-`.`(`a+`[psi[2]], Physics:-`.`(`a-`[psi[1]], `a-`[psi[2]])))-C*Physics:-`.`(`a+`[psi[3]], Physics:-`.`(`a+`[psi[4]], Physics:-`.`(`a-`[psi[3]], `a-`[psi[4]])))

(9)

 

Regarding your question about the algebra satisfied by annihilation/creation operators for fermionic or bosonic particles, the definitions used are the standard ones, see for instance the annihilation/creatioin operators in the wikipedia . Now, if you call Setup to display this algebra, you see

Setup(algebrarules)

[algebrarules = {%AntiCommutator(`a-`[psi[1]], `a+`[psi[1]]) = 1, %AntiCommutator(`a-`[psi[2]], `a+`[psi[2]]) = 1, %AntiCommutator(`a-`[psi[3]], `a+`[psi[3]]) = 1, %AntiCommutator(`a-`[psi[4]], `a+`[psi[4]]) = 1}]

(10)

and you asked what about the commutators for psi[i] <> psi[j]: their rules are automatically derived behind the scene, but you can check these derived rules directly, either using the Commutator and AntiCommutator commands, or the Library commands Commute and AntiCommute. For example:

 

Library:-AntiCommute(ap[1], ap[2])

true

(11)

Library:-AntiCommute(ap[1], am[3])

true

(12)

Therefore

0, "`%1` does not evaluate to a module", Library

true

(13)

0, "`%1` does not evaluate to a module", Library

false

(14)

Not directly related to SortProducts but related to the topic, there are now rules for changing variables in in Bras, Kets and Brackets

Setup(quantumoperators = {A, B})

[quantumoperators = {A, B}]

(15)

Sum(Physics:-`*`(Physics:-`*`(Physics:-`*`(f(n), alpha^(n-1)), Ket(A, n-1)), 1/sqrt(factorial(n-1))), n = 1 .. p+1)

Sum(f(n)*alpha^(n-1)*Physics:-Ket(A, n-1)/factorial(n-1)^(1/2), n = 1 .. p+1)

(16)

PDEtools:-dchange({n = k+1, f(n) = g(k)}, Sum(f(n)*alpha^(n-1)*Physics:-Ket(A, n-1)/factorial(n-1)^(1/2), n = 1 .. p+1))

Sum(g(k)*alpha^k*Physics:-Ket(A, k)/factorial(k)^(1/2), k = 0 .. p)

(17)


For some wrong reason Kets appear displayed in the contents above as question marks "?". In the output labeled (17) that "?" represents Ket(A, k) after changing variables.

Next in connection with these topics is Annihilation/Creation accepting symbolic occupation numbers and a new Library:-sum command that handles its arguments the same way as add does, but with the summation capabilities of sum - see sum with 'safe' dummy parameter design.

Download Update22.mw

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi

It is not clear what you meant passing [am, ap] as the ordering (second argument) to Library:-SortProducts. Note that you defined your annihilation/creation operators as am[i], ap[j], so am and ap are tables, only the table elements are the operators you want. For example, try has(z, am) and has(z, ap) and you see 'false'. Here are two possible interpretations that pass through my mind of what you tried to do and how you accomplish that using the current update of the Physics package (number 21, it is being posted in our website in the Physics updates page today): [worksheet ommited - corrected worksheet appears below in the next answer]

Regarding your question about collecting terms: if the factors you want collected are commutative, then the products involving them are so, hence you can use the Maple standard collect command (see ?collect). Otherwise you can use Physics:-Coefficients to manipulate the expression; a Physics:-Library:-Collect is not ready. You can always also use simplify/size (see ?simplify/size)

Edgardo S. Cheb-Terrab
Physics, Maplesoft

I just saw another post - same kind of problem, the same solution proposed here would cure it. I will prepare this prototype of sum command that handles the arguments the way add does while at the same time works with symbolic summation ranges and all the current summation knowledge of sum.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

This is the same type of problem discussed in recent posts about the dummy index of sum and the evaluation rules of the Maple standard 'sum' command,  see yesterday's post "Sum with safer dummy parameter design" 

And these are among the most frequent unexpected problems in Maple. See also the comment by Michael Croucher further below - as you Andriy, and many others along the years, he also finds this result by sum surprising. Please note that it doesn't matter here "why" is sum returning 0 - of course there is a logic, as explained by Carl below. In my opinion, however, the issue here is not that but the fact that this result is not what we want nor what we would expect.

Supporting the view of this result as 'unexpected' from a user perspective, check it out with add: to do the experiment you need to make the summation limits be integers, replace f by 1:

g := proc (i) 
if i = 1 then a else 0 fi
end proc:

h := add(g(i), i = 1 .. 1);
                                       a

Nice! So why is sum not returning alike? Because add and sum have different models for handling the arguments. I gave some details about this in "Sum with safer dummy parameter design". From my experience with add and sum I am convinced that 'add' has the correct model for handling of arguments, not sum. By 'correct' I mean: results by add are what I would expect right away, without using artificial tricks as delayed evaluation etc. On the other hand, sum has real and powerful summation knowledge, and handles symbolic summation ranges, and more, while add only handles integer ranges and only performs rudimentary addition one term at a time.

I will see to prepare a prototype for a sum command that uses the summation power of the current sum command but handles the arguments the way add does, so free of these problems.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi
I believe you are referring to the [] entering as first argument in the hypergeom function - these arguments are explained in ?hypergeom.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

 

Hi Peterm,

restart; with(Physics)

Setup(noncommutativepre = S)

`* Partial match of  'noncommutativepre' against keyword 'noncommutativeprefix'`

 

[noncommutativeprefix = {S}]

(1)

Set the algebra the way you did

PauliSigmaRules := seq(op([%AntiCommutator(S[j[1]], S[j[1]]) = 2, %Commutator(S[j[1]], S[j[2]]) = I*S[j[3]]]), j = [[x, y, z], [y, z, x], [z, x, y]])

Setup(PauliSigmaRules)

[algebrarules = {%AntiCommutator(S[x], S[x]) = 2, %AntiCommutator(S[y], S[y]) = 2, %AntiCommutator(S[z], S[z]) = 2, %Commutator(S[x], S[y]) = I*S[z], %Commutator(S[y], S[z]) = I*S[x], %Commutator(S[z], S[x]) = I*S[y]}]

(2)

With the today's update of Physics, downloadable from  "Maple Physics: Research & Development", it works as expected

Commutator(S[x], S[y])

I*S[z]

(3)

Commutator(S[x]^2, S[y])

0

(4)

Commutator(S[x]^3, S[y])

I*S[z]

(5)

AntiCommutator(S[x]^2, S[y])

2*S[y]

(6)

AntiCommutator(S[x]^2, S[y]^2)

2

(7)

The advantage of this with respect to what you can do without the updated Physics library is that in the above the algebra works right away, naturally, without having to define functions f and g as shown in the previous answer poseted.

Download PauliSigmaII.mw

Edgardo S. Cheb-Terrab
Physics, Maplesoft


Hi Mac Dude

 

PhysicsType is a package of specialized types distributed within the Physics,Library  and explained in that help page. Recalling, that I am working with the updated Physics library, downloadable from  "Maple Physics: Research & Development",

 

Physics:-Version()

"/Users/ecterrab/Maple/lib/Physics.mla", `2013, September 9, 12:23 hours`

(1)

the PhysicsVectors type you asked is included in the PhysicsType package:

 

with(Physics):

ListPhysicsTypes(PhysicsVectors, showdefinition)

[PhysicsVectors = proc (v, V::assignable) local ans, v0; option system; if v::'symbol' then ans := IsVectorSymbol(v) elif v::'indexed' then v0 := op(0, v); ans := v0::'symbol' and IsVectorSymbol(op(0, v)) elif not v::'algebraic' then ans := false else v0 := op(0, v); ans := v::'function' and v0::'{indexed, symbol}' and procname(v0) or `Identify/do`(v) <> 0 end if; if ans and 1 < nargs then GetVectorLabel(v, V) end if; procname(v) := ans end proc]

(2)

The*total*number*of*types*availablein*PhysicsType*is

nops(with(PhysicsType))

65

(3)

Download PhysicsType.mw

Edgardo S. Cheb-Terrab
Physics, Maplesoft

 

Hi Mac Dude

  

PhysicsType is a package of specialized types distributed within the Physics,Library  and explained in that help page. Recalling that I am working with the updated Physics library, downloadable from  "Maple Physics: Research & Development".

Physics:-Version()

"/Users/ecterrab/Maple/lib/Physics.mla", `2013, September 9, 12:23 hours`

(1)

The PhysicsVectors type you asked is included in the PhysicsType package.
 

with(Physics):

ListPhysicsTypes(PhysicsVectors, showdefinition)

[PhysicsVectors = proc (v, V::assignable) local ans, v0; option system; if v::'symbol' then ans := IsVectorSymbol(v) elif v::'indexed' then v0 := op(0, v); ans := v0::'symbol' and IsVectorSymbol(op(0, v)) elif not v::'algebraic' then ans := false else v0 := op(0, v); ans := v::'function' and v0::'{indexed, symbol}' and procname(v0) or `Identify/do`(v) <> 0 end if; if ans and 1 < nargs then GetVectorLabel(v, V) end if; procname(v) := ans end proc]

(2)

The*total*number*of*types*available*is

nops(with(PhysicsType))

65

(3)

 

Download PhysicsType.mw

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi Andriy

In the first reply it is shown how to perform to the end the computation you wanted to perform. In the second one I mentioned the implementation, in the downloadable update of Physics, of the simplification N^k = N, where N = ap . am and ap, am respectively represent criation, annihilation fermionic operators. Besides that, in the update of Physics posted today (dowloadable from the Maple Physics: Research & Development updates page) the simplification am^2 = 0 and ap^2 = 0 is also implemented, completing what has been discussed in this thread. Recalling, in connection with one of your questions, Andriy, these new simplifications are performed not using simplify but using Simplify, the command of the Physics package (see ?Physics,Simplify).

Edgardo S. Cheb-Terrab
Physics, Maplesoft


restart

diff(z(x, y), x, x)+2*(diff(z(x, y), x, y))+diff(z(x, y), y, y) = 0

diff(diff(z(x, y), x), x)+2*(diff(diff(z(x, y), x), y))+diff(diff(z(x, y), y), y) = 0

(1)

The transformation you posted:

itr := {u = x+y, v = x-y, omega(u, v) = x*y-z(x, y)}

{u = x+y, v = x-y, omega(u, v) = x*y-z(x, y)}

(2)

Rewrite your transformation with x, y and z(x, y) on the left-hand sides

tr := solve(itr, {x, y, z(x, y)})

{x = (1/2)*u+(1/2)*v, y = -(1/2)*v+(1/2)*u, z(x, y) = (1/4)*u^2-(1/4)*v^2-omega(u, v)}

(3)

Change variables

PDEtools:-dchange(tr, diff(diff(z(x, y), x), x)+2*(diff(diff(z(x, y), x), y))+diff(diff(z(x, y), y), y) = 0)

-4*(diff(diff(omega(u, v), u), u))+2 = 0

(4)

In the above you already see the answer to your question, so isolating omega[u, u]

isolate(-4*(diff(diff(omega(u, v), u), u))+2 = 0, diff(omega(u, v), u, u))

diff(diff(omega(u, v), u), u) = 1/2

(5)


Download PartialDerivative.mw

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi Peterm,


restart; with(Physics)

Setup(noncommutativepre = S, quiet)

[noncommutativeprefix = {S}]

(1)

Set your algebra as an algebra for powers of noncommutative operators, only two rules: one for Commutators, the other one for AntiCommutators, both rules respectively mapping into two functions f and g

Setup(%Commutator(S[a]^n, S[b]^m) = f(S[a], S[b], n, m), %AntiCommutator(S[a]^n, S[b]^m) = g(S[a], S[b], n, m))

[algebrarules = {%AntiCommutator(Physics:-`^`(S[a], n), Physics:-`^`(S[b], m)) = g(S[a], S[b], n, m), %Commutator(Physics:-`^`(S[a], n), Physics:-`^`(S[b], m)) = f(S[a], S[b], n, m)}]

(2)

Check it

AntiCommutator(S[a]^r, S[b]^s)

g(S[a], S[b], r, s)

(3)

Commutator(S[a]^r, S[b]^s)

f(S[a], S[b], r, s)

(4)

That is the most important part. You can now write f and g to accomplish the task in different ways.

 

Here is one way, starting with g

g := proc (A, B, n, m) if [n, m]::'Not(list(posint))' or `minus`({A, B}, {S[x], S[y], S[z]}) <> {} then ('AntiCommutator')(A^n, B^m) elif n::even then if m::even then 2 else AntiCommutator(1, B) end if elif m::even then AntiCommutator(A, 1) elif A = B then 2 else Physics:-`*`(A, B)+Physics:-`*`(B, A) end if end proc:

 

For f you need also to take care of cyclic permutations of [x, y, z] to get the correct sign; express first f  in terms of a procedure s, then concentrate on s

f := proc (A, B, n, m) if [n, m]::'Not(list(posint))' or `minus`({A, B}, {S[x], S[y], S[z]}) <> {} then ('Commutator')(A^n, B^m) elif A = B or n::even or m::even then 0 else I*remove(member, [S[x], S[y], S[z]], [A, B])[1]*s(A, B) end if end proc:

 

This is one possible way to code s

s := proc (A, B) options operator, arrow; if verify([A, B], [S[x], S[y], S[z], S[x]], sublist) then 1 else -1 end if end proc:

 

Check it out

s(S[x], S[y]), s(S[y], S[x])

1, -1

(5)

s(S[x], S[z]), s(S[z], S[x])

-1, 1

(6)

s(S[y], S[z]), s(S[z], S[y])

1, -1

(7)

All is in place. So now:

AntiCommutator(S[x], S[y])

Physics:-`*`(S[x], S[y])+Physics:-`*`(S[y], S[x])

(8)

AntiCommutator(S[x]^2, S[y])

2*S[y]

(9)

AntiCommutator(S[x]^2, S[y]^3)

2*S[y]

(10)

AntiCommutator(S[x]^4, S[y]^4)

2

(11)

Commutator(S[x], S[y])

I*S[z]

(12)

Commutator(S[x]^2, S[y])

0

(13)

Commutator(S[y]^3, S[x]^3)

-I*S[z]

(14)

Commutator(S[x]^4, S[y])

0

(15)

All this is reproducible in Maple 17, but anyway it is a good idea to update your Physics library - you can download it from the Maplesoft "Maple Physics: Research & Development" updates page. I will see next week to have things in place so that you can achieve the same results without having to write these f and g functions - say tackling this problem succesfully in a more natural way, similar to the one you tried.



Download PauliSigmaAlgebraRu.mw

 

Edgardo S. Cheb-Terrab
Physics, Maplesoft


Hi*ml76

I just saw your post ... answering two years after is probably irrelevant, but anyway: things have changed since 2011. Using the Physics library up-to-date (you can download it from the the "Maple Physics: Research & Development" updates page), current version:

Physics:-Version()

"/Users/ecterrab/Maple/lib/Physics.mla", `2013, September 6, 13:30 hours`

(1)

Set some commutation rules to see how it works

restart; with(Physics)

Setup(op = {A, B, C, f, g}, %Commutator(A, B) = 1, %Commutator(A, C) = g, %Commutator(B(x), C(y)) = f(x, y))

`* Partial match of  'op' against keyword 'quantumoperators'`

 

[algebrarules = {%Commutator(A, B) = 1, %Commutator(A, C) = g, %Commutator(B(x), C(y)) = f(x, y)}, quantumoperators = {A, B, C, f, g}]

(2)

The first commutator has a constant in the rhs: in these cases you can now index the operators A and B or give functionality to them as desired and the result will always be the right-hand side of type constant  :

Commutator(A, B)

1

(3)

Commutator(A(x), B(y))

1

(4)

Commutator(A[i](x), B[j](y))

1

(5)

In the second commutator, the right-hand side is not constant, so this one works as in previous releases:

Commutator(A, C)

g

(6)

Commutator(A(x), C(y))

Physics:-Commutator(A(x), C(y))

(7)

Commutator(A[i], C[j])

Physics:-Commutator(A[i], C[j])

(8)

The third commutator has functionality in the left-hand and right-hand sides, the same one, so in this case you have more flexibility

Commutator(B(x), C(y))

f(x, y)

(9)

Commutator(B(s), C(t))

f(s, t)

(10)

You can also transform f into a procedure

f := proc (x, y) options operator, arrow; x^y end proc

proc (x, y) options operator, arrow; Physics:-`^`(x, y) end proc

(11)

Commutator(B(u), C(w))

u^w

(12)

f := proc (x, y) options operator, arrow; 0 end proc

proc (x, y) options operator, arrow; 0 end proc

(13)

Commutator(B(a), C(b))

0

(14)

The Physics update is developed assuming the Maple 17 library, but the last approach, with f(x, y) in the right-hand side of the commutator followed by defining f as a procedure, will also work in previous Maples.


Download MaplePrimesCommutato.mw

Edgardo S. Cheb-Terrab 
Physics, Maplesoft

I suggest you to give a look at the section on Quantum Mechanics, subsection on Angular Momentum, within the help page ?Physics,Examples. The situation there illustrated is similar. From there you can either obtain what you want with few changes, or perhaps refine your question a bit more to help you more concretely.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

First 52 53 54 55 56 57 58 Page 54 of 59