The typesetting of Physics:-Library:-Add as a sum is finished and included in today's update of Physics.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

The typesetting of Physics:-Library:-Add as a sum is finished and included in today's update of Physics.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Andriy 

Regarding these other two questions you do in "Key issue": SortProducts has an option, evaluateexpression, so that after sorting the expression is evaluated. The difference when you use this option is that, when you evaluateexpression, a product `.`(A, B, C, D) becomes `.`(A, `.`(B, `.`(C, D))). At some point (years ago) it was relevant to keep `.` as a function of two arguments. I'd need to revise this to tell you exactly why was that ... or even if it is necessary today. Actually, if it is not necessary anymore, just remove it and keep the syntax as in `.`(A, B, C, D), the same way we do with Physics:-`*`.

Regarding your other question, given an expression that involves N products, say P[j] with j from 1 to N, and where each of these P[j] has a commutative factor that you called A[j], mutliplicating a noncommutative factor - say NC[j]. So say your expression is of the form ee := Sum(A[j] * NC[j], j=1..N), and let's suppose that the NC[j] involve both Physics:-`*` and Physics:-`.`. You want to get all the A[j]. There are simple ways of doing this systematically, but we would need another Library routine to unnest products in expressions - I will prepare it, include it in the next update of Physics this week and reply here again showing you how to do this.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Andriy 

Regarding these other two questions you do in "Key issue": SortProducts has an option, evaluateexpression, so that after sorting the expression is evaluated. The difference when you use this option is that, when you evaluateexpression, a product `.`(A, B, C, D) becomes `.`(A, `.`(B, `.`(C, D))). At some point (years ago) it was relevant to keep `.` as a function of two arguments. I'd need to revise this to tell you exactly why was that ... or even if it is necessary today. Actually, if it is not necessary anymore, just remove it and keep the syntax as in `.`(A, B, C, D), the same way we do with Physics:-`*`.

Regarding your other question, given an expression that involves N products, say P[j] with j from 1 to N, and where each of these P[j] has a commutative factor that you called A[j], mutliplicating a noncommutative factor - say NC[j]. So say your expression is of the form ee := Sum(A[j] * NC[j], j=1..N), and let's suppose that the NC[j] involve both Physics:-`*` and Physics:-`.`. You want to get all the A[j]. There are simple ways of doing this systematically, but we would need another Library routine to unnest products in expressions - I will prepare it, include it in the next update of Physics this week and reply here again showing you how to do this.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@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

@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