@Alejandro Jakubi 

I guess I've been unclear. The hybrid approach I am suggesting does not introduce any local nor it does any conversion, nor it requires tools for that. It works around evaluation levels instead: if m := n; and n := r; then eval(m, 1) gives n, eval(m, 2) gives r.

Taking this into account you can recursively strip (evaluate one level at a time each part of) an expression until a condition is reached, for example until the dummy is of type name - say then equal to j - and next you can recursively strip each part of the summand to the end or until you find j, and if you find it, stop evaluating that part. And in this way you never evaluate the summation index furthermore, while you perform a full evaluation of everything else in the summand. This is the way add works, a very nice model in my opinion, and is entirely different than the full evaluation performed by sum on all of its arguments - leading to some unexpected results as we frequently see posted. In brief, in this approach the match between the dummy index and its occurrences within the summand happens naturally, without introducing any local variables nor things of the like but through a careful manipulation of evaluation levels within the summand and summation variable.

To the side, a technicality but perhaps also a curiosity for whoever is reading this, it is true that add is a kernel command and does this stripping in a way that is not accessible from the library. But the Maple programming language is sophisticated enough to permit emulating this stripping very^very fast. I wrote a routine for that purpose when writing the assuming command, that strips expressions the same way until variables that are going to receive assumptions are found; think now of the summation to be performed and the dummy variable - the stripping requirement is basically the same, with the dummy being equivalent to the variables that are going to receive assumptions.

Yes, this approach, besides being simple and using a well tested routine at its core (the assuming routines have thousands^n hours of use), it also allows for a rapid prototyping: this first version shows 30 lines in showstat, and that includes interface, error messages, etc. The result: Physics:-Library:-Add, that is only a wrapping around sum, that handles the arguments such that the summation is performed free of the evaluation problems you have if you call sum directly. It works really nice.

Anyway I will welcome your suggestions or criticism around the concrete thing, next week, when you will have the opportunity to try it.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

The prototype is ready. It will be included in the next update of Physics distributed in the Maplesoft's Physics Updates page next week.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

The prototype is ready. It will be included in the next update of Physics distributed in the Maplesoft's Physics Updates page next week.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Alejandro Jakubi 

I do not understand precisely what you are saying. I wrote this post not suggesting a local dummy approach. There is no particular set of tools necessary to implement what I suggested. The evaluation model is the one of add, but without the restrictions of add, and using the summation code within sum while not suffering of the evaluation problems of sum (see recent posts about these problems here in Mapleprimes).

The prototype is ready. It will be included in the next update of Physics distributed in Maplesoft's Physics Updates webpage next week.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Carl Love 

Download IsHypergeometricTerm.mw

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Carl Love 

Download IsHypergeometricTerm.mw

Edgardo S. Cheb-Terrab
Physics, Maplesoft

This has been a week with a number of very interesting developments in Physics regarding quantum mechanics. Among them:

• The new command for sorting noncommutative products `*` and dot products `.` taking into account algebra (commutation and anticommutation rules set by the user or derived automatically) got enhanced rapidly in connection with people's feedback directly around the distributed updates.
• New expansion and combination rules of noncommutative powers, products and application of symbolic powers of quantum operators on Kets, as well as combinations and expansions of sum and Sum involving these noncommutative objects and taking assumptions into account.
• New rules for changing variables in Bras, Kets and Brackets, necessary when working with Projectors and doing manipulations with quantum states in Dirac notation.
• The handling of annihilation/creation operators got improved in several ways.
• New routines specialized in simplifying products of annihilation/creation operators.

Thanks to everybody that provided so valuable feedback here in Maplerimes and directly to physics@maplesoft.com.

Below is an exerpt of the changes that happened after Sep/9 as they appear illustrated in the PhysicsUpdates.mw distributed together with the update of Physics.

Edgardo S. Cheb-Terrab 
Physics, Maplesoft

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

Download UpdateWeekSep13.mw

@Andriy 

Hi, no embarrasement at all, we all make mistakes, and in fact you are correct, there is a bug in the last extension of the SortProducts code introduced yesterday (a variable that keeps track of sign gets incorrectly resetted), the expected for the second term of z starts with minus as you say. I'll be posting another update tomorrow fixing this problem together with some other changes.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Andriy 

Hi, no embarrasement at all, we all make mistakes, and in fact you are correct, there is a bug in the last extension of the SortProducts code introduced yesterday (a variable that keeps track of sign gets incorrectly resetted), the expected for the second term of z starts with minus as you say. I'll be posting another update tomorrow fixing this problem together with some other changes.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Alejandro Jakubi 

You have ee :=f(j); then you want sum(ee, j=1..3). That is one of the most frequent computations/scenarios.It wouldn't work with what you suggeest, with the summation index being a local. If you revise the original post where this problem was presented, a summation with a local dummy was also attempted - it was of no use for this same reason just mentioned.

What you see in seq and add, on the other hand, is actually a hybrid: the summand ee has a global j, and add, seq, mul, matches it to the summation index which in turn is not a global. What I am suggesting (original post) is precisely that hybrid model (so neither a global as sum uses, nor a local as you suggest), and with the summation knowledge of sum including accepting symbolic summation ranges, instead of the rudimentary knowledge of add and its error interruptions with symbolic ranges.

Edgardo S. Cheb-Terrab
Physics, Maplesoft.
Ps: very happy :)

@Carl Love 

There are two main differences between add and sum. First, for symbolic a and b,

> add(f(j, k), j = a .. b);
Error, unable to execute add

sum does not return this error (and for that reason the case of symbolic a, b is not mentioned in the post - that is not the problem). Note also that in the original thread annihilation/creation operators, add got mentioned as a possibility for performing the desired computation and discarded because of this error "unable to execute" the operation.

Second, sum has summation knowledge that goes far beyond adding one term at a time, both regarding definite and indefinite sums, not to mention the handling of formal sums; I skip here the details of all what sum can do and add cannot, presented in ?sum and ?sum,details.

So, no, add is not what we need here.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Andriy 

First of all, thank you for all your feedback. What you pointed at now is indeed a bug in the new implementation ofthese simplifications. A new updated (number 20) has just been posted in the Maple Physics: Research & Development updates page fixing the problem - with the fix we have:

Download am2_ap2_Nk.mw

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Andriy 

First of all, thank you for all your feedback. What you pointed at now is indeed a bug in the new implementation ofthese simplifications. A new updated (number 20) has just been posted in the Maple Physics: Research & Development updates page fixing the problem - with the fix we have:

Download am2_ap2_Nk.mw

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi

Just revising the Mapleprimes posts regarding the Physics package of the last 12 months. Besides some new interesting developments in connection with feedback by people using the package, the updated Physics downloadable from the Maplesoft "Maple Physics: Research & Development" webpage addresses the issues mentioned in the following Mapleprimes posts:

http://www.mapleprimes.com/questions/151320-Creation-And-Annihilation-Operators

http://www.mapleprimes.com/questions/151305-Evaluationsimplification-Of-Vector

http://www.mapleprimes.com/questions/149929-Types-In-The-Physics-Package

http://www.mapleprimes.com/questions/149012-Orthonormality-Issue-With-Bras-And-Kets

http://www.mapleprimes.com/questions/150378-Can-Maple-Handle-Dummy-Indices-Of-Tensors

http://www.mapleprimes.com/questions/148068-Getting-An-Error-With-A-Commutatoralgebra-Rule

http://www.mapleprimes.com/questions/142132-Is-There-A-Way-To-Get-The-Correct-Solution

http://www.mapleprimes.com/questions/129549-Fundiff-With-Anticommuting-Functions

http://www.mapleprimes.com/questions/120244-How-Do-I-Define-Commutators-Of-Operators

This novelty of distributing Physics updates around the clock is thus resulting in a very interesting twist, with Physics now partly developed directly around user's feedback with echo in a couple of days instead of the next release, when a fix one-year-after is frequently of no direct use.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Andriy 

Regarding your question 1): The workaround you suggest is not really a workaround: the step from (17) to (18) from the worksheet attached in my first reply won't work anymore, as you noticed, because the i within nn_operands is now a local variable (you declared it that way in your workaround) while the i in i = 1..2 in seq(nn_operands, i = 1..2) is a global variable. For the seq to proceed logically, these two i need to be the same.

Now, there are good reasons for not allowing assigning the summation dummy. Do you have a motivation for assigning it? Or is it only curiosity about how things work?

Regarding your question 2) on am2: enter, at the maple prompt, 

> am2;
                      am2

So, you see am2, not its contents. Now, am2 has not been declared as a quantum operator, then type(am2, Library:-PhysicsType:-ExtendedQuantumOperator); returns false. This is expected, the type doesn't scan the body of a procedure.

In connection you also quoted a sentence from the worksheet I posted: that sentence I wrote refers to am2 applied to arguments i, j, sigma, as in am2(i, j, sigma), and not to an unapplied am2 as you show.

Recalling: when the arguments passed, i, j, sigma, are numbers, the annihilation/creation operators are visible in the output of am2(i, j, sigma), and so the PhysicsType will recognized the construction as a quantum operator. If you do not apply am2, the annihilation/creation operators are not visible in the output of unapplied am2, so in order to have am2 recognized as an operator you need to set it as such using Setup. This same answer is the answer to your other question about N.

The logic of all this is understandable: a sum or product of quantum operators is a quantum operator. Enter the object at the Maple prompt, see what comes out: if the output shows quantum operators or a sum or product of them, PhysicsType will recognize the object as an operator. Otherwise, set the object as an operator using Setup (say as in Setup(op = {am, N, ..})) and that will suffice.

Regarding your question 3) to simplify N^k = N in these cases of fermionic occupation number operators, note that in my reply to you I used Simplify, from the Physics package (check ?Physics,Simplify), not simplify. Try Simplify - it works fine. Also, the simplification implemented  N^k = N applies to N = ap . am, and not to am^2 as you show - that would be another simplification to implement: am^2 = 0, likely: ap^2 = 0; I will see if we can have these other two in place as well in the next update this week.

Edgardo S. Cheb-Terrab
Physics, Maplesoft