Advanced Search

ecterrab

13331 Reputation

24 Badges

18 years, 151 days
Contact ecterrab

MaplePrimes Activity


These are answers submitted by ecterrab

Yes it is following its design principle...

ecterrab 13331
September 18 2013
1 0

@Carl Love 

Note that in the same page ?assuming[details] you are quoting, after these three items you quote, you also read:

Notes: The assuming command does not place assumptions on integration or summation dummy variables in definite integrals and sums, nor in limit or product dummy variables, because all these variables already have their domain restricted by the integration, summation or product range or by the method used to compute a limit. To obtain the simplification of the expression being summed, integrated or subject to a product taking into account the restriction on the values of the dummy variable implicit in the integration/summation/product range, use the simplify command -- see the Examples section of this help page.

The assuming command does not scan Maple programs regarding the potential presence of assumed variables. To compute taking into account assumptions on variables found in the bodies of programs, use assume -- see the Examples section.

These two paragraphs complete the description. Taking them into account, assuming does work according to its design.

Regarding the question by Sergio, the second paragraph quoted above is the answer. There are various reasons for this design, mainly that if you scan procedures, they typically call other procedures that call other ones etc. and you cannot go scanning all the tree, and "I only scan this many levels" would be of no use in various cases one could imagine, and you have the functionality anyway if you use assume alone or in combination with assuming (with or without its option additionally). There is one example in the Examples section illustrating this aspect of the design explicitly.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Physics:-Library:-Add...

ecterrab 13331
September 17 2013
0 1

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

AntiCommutator and Coefficients improved...

ecterrab 13331
September 17 2013
2 7

@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

working as expected (update 22) and chan...

ecterrab 13331
September 13 2013
2 3

@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

unclear .. new Physics update...

ecterrab 13331
September 12 2013
2 2

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

more of the same...

ecterrab 13331
September 12 2013
0 1

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

same problem. same solution...

ecterrab 13331
September 12 2013
1 1

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

The hypergeometric pFq function...

ecterrab 13331
September 10 2013
1 1

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

Algebra for Pauli matrices...

ecterrab 13331
September 09 2013
1 1

 

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

Library:-PhysicsType package...

ecterrab 13331
September 09 2013
1 0


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

PhysicsType...

ecterrab 13331
September 09 2013
0 0

 

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

new: am^2 = 0 ap^2 = 0 for fermionic am ...

ecterrab 13331
September 09 2013
2 4

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

Change variables...

ecterrab 13331
September 09 2013
1 0


> 

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

Yes by setting an algebra for powers of ...

ecterrab 13331
September 07 2013
1 0

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

How to do it with current or previous Ph...

ecterrab 13331
September 06 2013
1 0


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

First 48 49 50 51 52 53 54 Page 50 of 55