@Andriy 

First: the issue of extracting the A[alpha] from an operator H, where the A[alpha] is a commutative factor, this is the issue you have been discussing in this thread, is resolved: you can use coeff or Physics:-Coefficients with a product as second argument.

Today you introduced a different thing: getting the coefficient of a noncommutative variable within a noncommutative product. Physics:-Coefficients can do that for anticommutative variables, and also for noncommutative variables provided that the meaning is not ambiguous: suppose A, B and C are noncommutative then what is the coefficient of A in ABC, BAC and BCA?

I see three possible answers:
1) it is BC in all the cases. But then we have a problem: you cannot reconstruct the input given the coefficient BC and the variable A.

2) it is BC in the first case and interrupt with an with an error in the second and third cases. This is the current design. I see however that I forgot to mention this exception that it works when the variable is in the first position of a noncommutative product - I need to fix the help page regarding this.

3) It interrupts with an error in the three cases.

So, what is what you were expecting from Coefficients that is not this error interruption, or what is what you would suggest?

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Alejandro Jakubi 

Regarding your question about this new Physics:-Library:-Add: "Specifically, does the same recommendation of always explicitly declare the index variable to be local inside procedures hold also for this new routine?" The answer is: no, not at all. no local variables, no declarations of them inside procedures. Nada. Just use it normally and it is free of the issues with evaluation of arguments or local variable declarations of both sum and add. 

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Alejandro Jakubi 

Physics:-Library:-Add is there in today's update of Physics. Now, of course the program, as any other Maple program, uses internal routines, and these are not meant for user-level use (which I see from your posts you apparently insist they should be documented as if they were user-level). They are then not documented the way you would like nor they will be. We know that. Partly for this reason is that I introduced the ?Physics:-Library, and ?PDEtools:-Library subpackages and related documentation - see also ?dsolve[setup], but these are exceptions.

On the other hand, one of the things that distinguishes Maple, fantastic thing, is that you can list all the not-user-level-documented library internal routines for inspection, tracing, and even rewriting them if you want. We all learned a lot in that way, and many of us actually switched to, or use Maple today, solely for that reason. Concretely, the routine you are curious about, at the root of this stripping of expressions in use in this new user level routine Physics:-Library:-Add, is `assuming/set_expression`.

I do not feel your question about the meaning of the second parameter in seq as quite within the scope of this post. You may prefer to ask this question in a new/separated post.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Andriy 

In my reply yesterday (see above) I mentioned taking the coefficients "of a product". I also put an example showing that working. Have you tried today's Physics update? I understand Coefficients can do what you need, i.e. to grab all that A[alpha] from H. 

For example: take your z2 (shown as (22) in my reply yesterday - see above) and compute '> Coefficients(z2, ap[1].am[1], 1)' and you will receive, 'R + 3', which is the A[alpha] you are asking.

Additionally, besides Coefficients that can break into a noncommutative product, note that the output of Physics:-`*` as well as that of Physics:-`.` is of the form sorted_s1 * non_commutative_sorted_s2, where the * between them is the commutative standard Maple product, while non_commutative_sorted_s2 is a noncommutative product internally represented as a function. For this reason, you can always use the standard collect and coeff commands to collect (that is why it works colleting the function Physics:-`.`) and to get the coefficients of non_commutative_sorted_s2 (i.e. these A[alpha]; try it).

If today's update doesn't work the way you need, posting a concrete example as the other times will facilitate helping you filling the gaps or developing the functionality missing if any. Thanks.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Andriy 

In my reply yesterday (see above) I mentioned taking the coefficients "of a product". I also put an example showing that working. Have you tried today's Physics update? I understand Coefficients can do what you need, i.e. to grab all that A[alpha] from H. 

For example: take your z2 (shown as (22) in my reply yesterday - see above) and compute '> Coefficients(z2, ap[1].am[1], 1)' and you will receive, 'R + 3', which is the A[alpha] you are asking.

Additionally, besides Coefficients that can break into a noncommutative product, note that the output of Physics:-`*` as well as that of Physics:-`.` is of the form sorted_s1 * non_commutative_sorted_s2, where the * between them is the commutative standard Maple product, while non_commutative_sorted_s2 is a noncommutative product internally represented as a function. For this reason, you can always use the standard collect and coeff commands to collect (that is why it works colleting the function Physics:-`.`) and to get the coefficients of non_commutative_sorted_s2 (i.e. these A[alpha]; try it).

If today's update doesn't work the way you need, posting a concrete example as the other times will facilitate helping you filling the gaps or developing the functionality missing if any. Thanks.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@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 :)