11116 Reputation

24 Badges

16 years, 323 days

MaplePrimes Activity

These are replies submitted by ecterrab

In the latest Maplesoft Physics Updates (v.1235) there is a fix to "not placing the default nonnegint assumption" I mentioned a couple of replies above. So with the latest Physics Updates for Maple 2022, we now get

> D[1 $ j, 2 $ k](f)(x, y);  # computes both derivatives, x$j and y$k

                  /   k                                                 /

                  | -----                                               |

                  |  \                                      (2 j - _k1) |

pochhammer(-j, j) |   )    binomial(k, _k1) GAMMA(1 + 2 j) y            | ...

                  |  /                                                  |

                  | -----                                               |

                  |_k1 = 0                                              |

                  \                                                     \


> eval(value(eval(%, [ j = 2, k = 4 ])), y = 0);



PS: @Carl Love, although I see the motivation for your comment, I don't foresee adding to the diff command an option like "return a piecewise with all the cases".  The design of diff is to return a default value, and handle assumptions when possible - only that. It is similar to how the conversion network for mathematical functions works (see ?convert, to_special_function).

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

I pointed out that the symbolic differentiation result, for symbols j and k, is correct. You objected to that. I only replied showing that, indeed, the result is correct. That closes the question.

Next you pointed out that the symbolic differentiation result is fragile. That concept is debatable. I do agree though, with a previous comment by you, that the most common situation is j, k nonnegint; so if choosing a way to express the result using GAMMA functions, do that for the most common case. The symbolic differentiation code is already doing that. But not in one branch of a subroutine, and the problem posted hits that branch. Although the result is correct, it can be better. It is something to adjust.

But then you come up with applying blindly the manipulation I used for the default output, after (you) using the opposite assumptions. With due respect, @vvI don't see your point. You realize that if the result contains GAMMA as in this example, under direct evaluation it will either work with j negint, or for j posint, and not with both at the same time.

Add to that my opinion, that returning piecewise functions all around is not a convenient idea. Instead, I prefer presenting results with a convenient default and leave to the user to use assumptions for the other cases. Also relevant: understand that having Sums, and especially in the higher-order symbolic differentiation case, the results may require additional algebraic manipulations when evaluating the symbols involved at some values; typically, cases where correctness would require using limits or removing apparent singularities.

Returning to your example assuming j::nonegint, k::nonegint (above this reply), the manipulation after ex1 is as follows:

ex2 := simplify(eval(ex1, [j=2,k = 4, Sum = add]), GAMMA);
simplify(eval(ex2, [y=0]));

So, the result by the symbolic differentiation code is also correct when assuming j::nonegint, k::nonegint.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft


It is about removable/apparent singularities.

f := proc (x, y) options operator, arrow; 1/(2+x*y^2) end proc

(D[`$`(1, j), `$`(2, k)](f))(x, y)

pochhammer(-j, j)*(Sum(binomial(k, _k1)*(-1)^_k1*y^(-_k1)*(y^2)^j*GAMMA(-2*j+_k1)*(diff((x*y^2+2)^(-1-j), [`$`(y, k-_k1)]))/GAMMA(-2*j), _k1 = 0 .. k))


We know that, for x = 0, y = 0, j = 2, k = 4 the value of (D[`$`(1, j), `$`(2, k)](f))(x, y)is 6, the issue is whether the answer above is or is not correct:


simplify(eval(pochhammer(-j, j)*(Sum(binomial(k, _k1)*(-1)^_k1*y^(-_k1)*(y^2)^j*GAMMA(-2*j+_k1)*(diff((x*y^2+2)^(-1-j), [`$`(y, k-_k1)]))/GAMMA(-2*j), _k1 = 0 .. k)), [k = 4, Sum = add]), GAMMA)

8*(x*y^2+2)^(-1-j)*(32*j^4+(-208*x*y^2-96)*j^3+(366*x^2*y^4+216*x*y^2+88)*j^2+(-180*x^3*y^6+18*x^2*y^4-56*x*y^2-24)*j+15*x^4*y^8-60*x^3*y^6+12*x^2*y^4)*pochhammer(-j, j)*(y^2)^j/((x*y^2+2)^4*y^4)


eval(8*(x*y^2+2)^(-1-j)*(32*j^4+(-208*x*y^2-96)*j^3+(366*x^2*y^4+216*x*y^2+88)*j^2+(-180*x^3*y^6+18*x^2*y^4-56*x*y^2-24)*j+15*x^4*y^8-60*x^3*y^6+12*x^2*y^4)*pochhammer(-j, j)*(y^2)^j/((x*y^2+2)^4*y^4), [j = 2, x = 0])





Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

Hi @vv 

The problem you point at is in `eval/Sum`. Not in sum and not in D, both work correctly, that is why D[1$2,2$4](f)(0,0) returns 6, correct. To see the problem in `eval/Sum` try

f := (x, y) -> 1/(2 + x*y^2):
D[1 $ j, 2 $ k](f)(x, y);  # correct result for the jth and kth symbolic derivative


eval(%, [x = 0, y = 0]);  # problem in `eval/Sum`
                                   /   k     \
                                   | -----   |
                                   |  \      |
                 pochhammer(-j, j) |   )    0|
                                   |  /      |
                                   | -----   |
                                   \_k1 = 0  /


Regarding your first question, the command to use is Library:-SubstituteOperator. Your reply indirectly introduces two more questions, one about reordering noncommuting operators, the command is SortProducts, and the other one is about commutativity of indexed quantum operators - use noncommutative variables instead, or quantum tensorial operators.


Finally, when you present a power as in A[1]*B[2]*B[2] = A[1]*B[2]^2, the code was requiring an extra argument to act on powers. I changed that default behavior so it now acts on powers automatically (unless you explicitly specify otherwise) - so for that you need to update to the latest Maplesoft Physics Updates version 1126. The rest of what follows doesn't require that.


Formulating the problem,

with(Physics); Setup(quantumoperators = {A, B, C})

[quantumoperators = {A, B, C}]


Setup(algebrarules = {%Commutator(A[m], B[n]) = C[m+n]})

[algebrarules = {%Commutator(A[m], B[n]) = C[m+n]}]


The answer to your original question is Library:-SubstituteOperator

Library:-SubstituteOperator(A[1]*B[2] = 5, A[1]*B[2]*B[3]+C[3])



Next question, when you are substituting into noncommutative operators, the order of the operands is relevant. For example, this doesn't work:

('Library:-SubstituteOperator')(A[1]*B[2] = 5, A[1]*B[2]*B[3]+C[3])

Physics:-Library:-SubstituteOperator(Physics:-`*`(A[1], B[2]) = 5, Physics:-`*`(B[2], A[1], B[3])+C[3])


Physics[Library]:-SubstituteOperator(Physics[`*`](A[1], B[2]) = 5, Physics[`*`](B[2], A[1], B[3])+C[3])

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


Why? Because A[1]*B[2] <> A[1]*B[2]. So first you'd need to sort products, and in doing so any commutator rule is automatically taken into account. For example in view of

(%Commutator = Commutator)(A[2], B[1])

%Commutator(A[2], B[1]) = C[3]


The following two-step operation works

SortProducts(Physics[`*`](B[2], A[1], B[3])+C[3], [A[1], B[2]])

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


Library:-SubstituteOperator(A[1]*B[2] = 5, Physics[`*`](A[1], B[2], B[3])-Physics[`*`](C[3], B[3])+C[3])

5*B[3]-Physics:-`*`(C[3], B[3])+C[3]


One could make these two steps be automatically be only one step, at the cost of having less control; something to think about.


Next, about commutation:

Library:-Commute(B[1], B[2])



Why is that? Because setting B as a quantum operator results in this action on kets.

B[1].Ket(B, m, n)

m*Physics:-Ket(B, m, n)


B[2].Ket(B, m, n)

n*Physics:-Ket(B, m, n)


That is, B[1] and B[2] are operators that act on disjointed spaces, the indexation is used to select the corresponding eigenvalue in a tensor product of states Ket(B, m, n), therefore B[1] and B[2] commute.


You could avoid this subtlety if you work with noncommutative variables as opposed to quantum operators. For example

Setup(noncommutativeprefix = Z)

[noncommutativeprefix = {Z}]


Library:-Commute(Z[1], Z[2])



You can also give a different meaning to quantum operators B[1] and B[2] and, in doing so, indicate they do not commute. Suppose you know the dimension of the index, for example 3; e.g. angular momentum. Define a tensor with its components here I use a different letter but any letter is as good

Setup(spaceindices = lowercaselatin_is, op = L, tensors = L[m])

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




[quantumoperators = {A, B, C, L}, spaceindices = lowercaselatin_is, tensors = {Physics:-Dgamma[mu], L[m], Physics:-Psigma[mu], Physics:-d_[mu], Physics:-g_[mu, nu], Physics:-gamma_[i, j], Physics:-LeviCivita[alpha, beta, mu, nu]}]


So now

Library:-Commute(L[1], L[2])



You see the dimension around:


Physics:-`*`(L[m], L[`~m`])


SumOverRepeatedIndices(Physics[`*`](L[m], L[`~m`]))

Physics:-`*`(L[1], L[`~1`])+Physics:-`*`(L[2], L[`~2`])+Physics:-`*`(L[3], L[`~3`])


Now suppose you do not know the dimension. You can still define tensor of a space with unknown dimension, here generally called "gauge". So define corresponding indices and a tensorial quantum operator F[a] of that space

Setup(gaugeindices = lowercase_ah, op = F, tensors = F[a])

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




[gaugeindices = lowercaselatin_ah, quantumoperators = {A, B, C, F, L}, tensors = {Physics:-Dgamma[mu], F[a], L[m], Physics:-Psigma[mu], Physics:-d_[mu], Physics:-g_[mu, nu], Physics:-gamma_[i, j], Physics:-LeviCivita[alpha, beta, mu, nu]}]


Again, the components don't commute

Library:-Commute(F[1], F[2])



This time the dimension is not known, so for example the sum over the repeated indices cannot be performed:


Physics:-`^`(F[a], 2)


SumOverRepeatedIndices(Physics[`^`](F[a], 2))

Physics:-`^`(F[a], 2)


Still, tensorial simplification operations continue working


Physics:-`^`(F[a], 2)-Physics:-`^`(F[b], 2)


Simplify(Physics[`^`](F[a], 2)-Physics[`^`](F[b], 2))



KroneckerDelta[a, b]*F[b]

Physics:-KroneckerDelta[a, b]*F[b]


Simplify(Physics[KroneckerDelta][a, b]*F[b])



Now to handle powers


Physics:-`*`(A[1], Physics:-`^`(B[2], 2))-Physics:-`*`(C[3], B[3])+C[3]


without updating to the latest Physics Updates, you'd need to add the word 'true' at the end of the arguments passed. After installing the latest Physics updates that is not necessary:

Library:-SubstituteOperator(A[1]*B[2] = 5, Physics[`*`](A[1], Physics[`^`](B[2], 2))-Physics[`*`](C[3], B[3])+C[3])

5*B[2]-Physics:-`*`(C[3], B[3])+C[3]


PS: when using the Green Arrow to insert a worksheet, you can also ask for the contents to be shown, and filename.maple are not recommended for upload; use instead.

Download SubstituteOperator_(II).mw

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft


But then you need to write the preamble properly - and that is not what you are doing. One workaround is for you to convert any worksheet, get the right preamble, then use it as a template. If that doesn't work AND you keep not posting a worksheet (do you expect people to start reading your image and trying to reproduce by typing etc.?), there is no chance.

Anyway, this is my last reply to this thread.

@etian2  I don"t see your worksheet. Also, the heading of the file you show is not the one you get ia File >Export> Latex. 


From your answers, guesswork is not helping. Let's move away from guessing. Could you please post the worksheet you are translating to LaTeX? I will give it a look.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft.


In usepackage, it is maple(.sty). Not maple2e(.sty). Yes you need to copy the sty files to the directory where you put the tex file, that is the standard LaTeX procedure for sty files.


type a_ + b_ anywhere, say within the text. Then mark the equation with the mouse, right-click, convert to > 2D-math non-executable, and you will see it with the arrow on top, as you say, symbols in nonexecutable math.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft


I imagine you did not input kernelopts(mapledir) to see what directory the help page is indicating - Is it that? So, enter kernelopts(mapledir) at the Maple prompt, see what directory it indicates, open the file manager there and you will see a subdirectory called "etc", within which there is maple.sty. All Maple installations are the same.


I'm glad to hear that more people are excited about Maple's developments in theoretical physics. Your comment is an opportunity to shed some light on what this is about - why the words I used in this post.

Note first that four different packages converge in this development: FeynmanDiagrams, FeynmanIntegral, Physics, and new in Maple 2022: StandardModel. These packages were all developed in consultation with actual practising theoretical physicists; see the Maple Physics: Research & Development.

The FeynmanDiagrams and FeynmanIntegral packages both involve several commands for performing all or each of the steps of the computations of scattering amplitudes and Feynman integrals. We do that in both coordinates and momentum representation - feynarts cannot do that. Then FeynmanIntegral performs (with restrictions, however) the symbolic computation of these integrals, which is also not possible with the packages you mention. FeynmanDiagrams and FeynmanIntegral implement relevant functionality available in computer algebra for the first time, presented in Computer Algebra and Particle Physics - CAPP 2021.

Now, it is true that we didn't contact the authors of the packages you mentioned. But there is a reason. All but one are implementations in Mathematica. Still, two papers are being finished about FeynmanDiagrams and FeynmanIntegral, and as is standard in these cases, both papers include tables comparing functionality - and yes: there we talk about the packages you mention. By the way, about FeynRules (feynrules.irmp.ucl), note that in the Maple implementation, due to having functional differentiation available as a command, the Feynman rules are computed automatically, on the flight, for any possible QFT model, turning unnecessary a package for just that.

The fourth package you mention is implemented in FORM, not a general-purpose computer algebra system. It is not possible to implement in FORM something like what you see in Maple Physics even if you restrict the goal to what is shown above for this new StandardModel package.

Perhaps more important, each of FeynmanDiagrams, FeynmanIntegral, Physics and StandardModel has several commands that can work in black box or all the steps approach. When compared with previously existing software in other platforms, four things in this Maple Physics environment appear to be unique:

  • The implementation has an emphasis not just on research but also on education. That is what I meant with all the steps approach.
  • The notation, both for input and output, is basically as in textbooks to the point that during presentations, sometimes people ask whether I am showing LaTeX or Maple. That this notation includes functional copy (from output) & paste (on input) increases the usability significantly.
  • Things can be set and changed effortlessly. For example, you can set the interaction Lagrangian for a model in 1/2 line (no need to write a text file as with feynarts) and compute scattering amplitudes in coordinates or momentum representation right away. For the StandardModel, we added a command, Lagrangian, to retrieve its different sectors or all of them. This command is relevant due to the large number of terms of the model, and because of the several different kinds of tensor indices necessary to algebraically represent it.
  • The implementation of mathematical objects and related operations starts at a very deep level. Both the differentiation and product operators are redefined entirely. They handle noncommutative, anticommutative and commutative objects as we do with paper and pencil, including in that user-defined: tensors of different kinds, differential, Hermitian, Unitary, etc. quantum operators with their properties, commutator algebra rules, disjointed Hilbert spaces, etc. No wonder why for Maple 2022 we were able to implement the new StandardModel package; it is built on top of all that.

This is the help page of; it illustrates the itemization above.

While, in general, I'd agree with you on the meaning of "a remarkable achievement in computational physics", the capability to represent such different mathematical objects with their properties set, as well as to perform such different operations with them in so a versatile way and so similar to what we do with paper and pencil, all that I think is indeed a remarkable achievement in computational physics. 

Finally, regarding performing previously impossible novel calculations published in peer-reviewed journals, while that is possible, our approach is, as said, to implement both education and research-level capabilities with the bar as high as we can see (and for that, yes we take a peek at the existing software). In this way, it is possible to achieve a remarkable computational implementation independent of having already a previously impossible result at hand.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

Yes. This post is only about Physics & Maple 2022, but it doesn't mean, 'less mathematics.'

My comment (see the previous reply) about work on the Appell doubly hypergeometric functions and advanced symmetry methods for differential equations is an example of what you could call "Mathematics too." To mention a few more, there are the Differential Algebra and Differential Geometry packages, or the FunctionAdvisor and the conversion network for mathematical functions. All of those are notable developments that only exist in the Maple system. They also bring to the tips of the fingers true computational power, not in physics but mathematics. Both things are true.

That said, there are more things to do. I forwarded your comment to the people currently in charge of the numerical methods for the Zeta function.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions


At Fermilab, physicists have recently found that the W boson appears to be 0.1% too heavy. That would contradict previous experiments weighing the W. If the new result is confirmed to be more accurate than the previous ones, it would be fantastic and propel one more round refining the mathematical model that represents elementary particles in nature, the building blocks of everything.

But the act of refining our understanding of things does not disqualify our current knowledge. For example, we know that quantum mechanics and general relativity cannot both be true as we understand them today. And yet the technology we use today, cellphones and the internet to mention something trivial, is 100% based on both of them.

Copying from the post about this new Fermilab measurement of the mass of the W: "The Standard Model of particle physics is the most successful scientific theory of all time." It is not taught in simple terms in elementary or high school though, yet. It could, and that would stimulate the curiosity of millions.

In this excellent "YouTube visual presentation of the Standard Model for the non-expert," Cambridge University physicist David Tong recreates the model piece by piece and provides a conceptual understanding of how it works. This is the kind of material that could be, and is in fact presented in some more modern high schools in Canada. That shouldn't surprise anybody; the Pauli exclusion principle currently taught in high-school, was the equivalent of "the standard model" not many years ago.

But then, besides our conceptual understanding of things at the teen's level, at the university level we want to work with the mathematics behind those concepts. There is where computer algebra can make a great difference, putting complex mathematical methods at the tip of our fingers. True computational power for everybody. That facilitates more and more people to immerse in the ideas and concepts instead, from advanced Appell special functions to symmetry methods for differential equations and the realm of particle physics. That is the way I see computer algebra participating in the evolution of science.

By the way, the whole Physics package is aligned with that vision: to facilitate people's immersion in the ideas and concepts by providing versatile implementations of the mathematical methods of physics, from Quantum Mechanics to General Relativity, or now Particle Physics and its Standard Model, and I am proud of working for a company, Maplesoft, that not only has this vision but also is at the frontier of developing it.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions


The automatic redefinition of the summation range, mentioned in the previous answer, taking advantage that some terms are equal to zero due to the presence of a KroneckerDelta; and then the subsequent simplification of that KroneckerDelta removing a sum, possible only after redefining the range of the other sums within a multiple sum, is now implemented.


So with the latest Maplesoft Physics Updates (v.1190 and higher) we get:


`The "Physics Updates" version in the MapleCloud is 1190 and is the same as the version installed in this computer, created 2022, April 1, 17:45 hours Pacific Time.`



H := sum(Ket(e, n).Bra(e, n+1)+Ket(e, n+1).Bra(e, n), n = 1 .. d)


sum(Physics:-`*`(Physics:-Ket(e, n__1), Physics:-Bra(e, n__1+2)), n__1 = 1 .. d-1)+sum(Physics:-`*`(Physics:-Ket(e, n__1), Physics:-Bra(e, n__1)), n__1 = 1 .. d)+sum(Physics:-`*`(Physics:-Ket(e, n+2), Physics:-Bra(e, n)), n = 1 .. d-1)+sum(Physics:-`*`(Physics:-Ket(e, n__1+1), Physics:-Bra(e, n__1+1)), n__1 = 1 .. d)


Note that the two sums that take terms off the diagonal now have, automatically, the upper summation value diminished by 1, taking advantage that for n__1 = d, the KroneckerDelta delta[n, n__1+1] is equal to 0 since n <= d. That is equivalent to splitting "(&sum;)=((&sum;)+<term with `n__1`=d>)", where the separate term for n__1 = d is equal to zero as mentioned.


The new automatic simplification also happens when passing directly to the simplifier the double sum we were getting before this change:

sum(sum(delta[n, n__1+1]*Ket(e, n__1)*Bra(e, n+1)+delta[n__1, n+1]*Ket(e, n__1+1)*Bra(e, n), n = 1 .. d)+Ket(e, n__1+1)*Bra(e, n__1+1)+Ket(e, n__1)*Bra(e, n__1), n__1 = 1 .. d)

sum(sum(Physics:-KroneckerDelta[n, n__1+1]*Physics:-`*`(Physics:-Ket(e, n__1), Physics:-Bra(e, n+1))+Physics:-KroneckerDelta[n__1, n+1]*Physics:-`*`(Physics:-Ket(e, n__1+1), Physics:-Bra(e, n)), n = 1 .. d)+Physics:-`*`(Physics:-Ket(e, n__1+1), Physics:-Bra(e, n__1+1))+Physics:-`*`(Physics:-Ket(e, n__1), Physics:-Bra(e, n__1)), n__1 = 1 .. d)


Simplify(sum(sum(Physics[KroneckerDelta][n, n__1+1]*Physics[`*`](Physics[Ket](e, n__1), Physics[Bra](e, n+1))+Physics[KroneckerDelta][n__1, n+1]*Physics[`*`](Physics[Ket](e, n__1+1), Physics[Bra](e, n)), n = 1 .. d)+Physics[`*`](Physics[Ket](e, n__1+1), Physics[Bra](e, n__1+1))+Physics[`*`](Physics[Ket](e, n__1), Physics[Bra](e, n__1)), n__1 = 1 .. d))

sum(Physics:-`*`(Physics:-Ket(e, n__1), Physics:-Bra(e, n__1+2)), n__1 = 1 .. d-1)+sum(Physics:-`*`(Physics:-Ket(e, n__1), Physics:-Bra(e, n__1)), n__1 = 1 .. d)+sum(Physics:-`*`(Physics:-Ket(e, n+2), Physics:-Bra(e, n)), n = 1 .. d-1)+sum(Physics:-`*`(Physics:-Ket(e, n__1+1), Physics:-Bra(e, n__1+1)), n__1 = 1 .. d)


One can still argue that (3) is "simpler" than (4), but while that is a valid point of view I still prefer  (4) since it has sums with no KroneckerDeltas while that is not the case of (3) , and that is the condition tested by the program before returning an expanded result.



Download hopping_(reviewed_II).mw

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

1 2 3 4 5 6 7 Last Page 1 of 53