Applications, Examples and Libraries

Share your work here

Just a simple little worksheet to see if I have enough propane to heat my house for the rest of the winter.


 

Do I have enough propane for the winter?

NULL

I've taken some measurements from my propane tank throughout the winter.  Now we can use Maple to see if we have enough to last the rest of the winter.

``

a := [["nov 27, 2017", 73.5], ["dec 9, 2017", 72], ["dec 16, 2017", 69], ["dec 31, 2017", 62], ["jan 12, 2018", 60], ["jan 19, 2018", 56], ["jan 26, 2018", 54], ["feb 4,2018", 51]]

[["nov 27, 2017", 73.5], ["dec 9, 2017", 72], ["dec 16, 2017", 69], ["dec 31, 2017", 62], ["jan 12, 2018", 60], ["jan 19, 2018", 56], ["jan 26, 2018", 54], ["feb 4,2018", 51]]

(1)

with(Finance)  ``

pts := [seq([DayCount(a[1, 1], a[i, 1]), a[i, 2]], i = 1 .. nops(a))]

[[0, 73.5], [12, 72], [19, 69], [34, 62], [46, 60], [53, 56], [60, 54], [69, 51]]

(2)

with(plots)

listplot(pts)

 

Adding a 30% and 20% level to the graph.  We probably shouldn't be too worried about the cold in June so DayCount("Nov 27, 2017", "Jun 1, 2018") = 186 we'll extend these reference lines out to 186.

plot({pts, [[0, 20], [186, 20]], [[0, 30], [186, 30]]}, view = [default, 0 .. 80])

 

 

30% is the recommended level your propane company wants you to fill up at.  The technician who installed the tank said 20% is all right.  It's up to you if you want to go to 10% but if you run out of propane the company has to come in and do a leak test on your system which is an added cost you don't want.  So let's predict at what point we need to start worrying about filling up our propane tank.  To do that, of course, all we need is a forecast line.  For that we'll just calculate a best fit.

 

a1 := [seq(DayCount(a[1, 1], a[i, 1]), i = 1 .. nops(a))]

[0, 12, 19, 34, 46, 53, 60, 69]

(3)

a2 := a[() .. (), 2]

[73.5, 72, 69, 62, 60, 56, 54, 51]

(4)

X := convert(a1, Vector)

Y := convert(a2, Vector)

with(Statistics)

L1 := LinearFit([1, x], X, Y, x)

HFloat(74.79237702730747)-HFloat(0.34416046490941915)*x

(5)

Plotting it all together

plot({L1, pts, [[0, 20], [186, 20]], [[0, 30], [186, 30]]}, x = 0 .. 200, y = 0 .. 80, labels = ["Days", ""], tickmarks = [default, [seq(10*i = cat(10*i, "%"), i = 1 .. 8)]])

 

Projecting the line to 30% we get

solve(L1 = 30)

130.1496877

(6)

AdvanceDate(a[1, 1], trunc(solve(L1 = 30)))

Record(monthDay = 6, month = 4, year = 2018, format = "%B %e, %Y", ModulePrint = proc (m) Finance:-FormatDate(m) end proc)

(7)

April is still a bit chilly so maybe if we wait until 20%, of course it's getting warmer all this time so our usage should go down.  

AdvanceDate(a[1, 1], trunc(solve(L1 = 20)))

Record(monthDay = 5, month = (), year = 2018, format = "%B %e, %Y", ModulePrint = proc (m) Finance:-FormatDate(m) end proc)

(8)

It isn't warm enough to turn off the furnace yet but it looks like we'll have enough to get us into the warm months

AdvanceDate(a[1, 1], trunc(solve(L1 = 10)))

Record(monthDay = 3, month = 6, year = 2018, format = "%B %e, %Y", ModulePrint = proc (m) Finance:-FormatDate(m) end proc)

(9)

We'll hit 10% well into late spring and almost right into summer of course it's a rough estimate however it looks like we won't have to fill up during the high price winter season.  I can tell my wife to relax, we should have enough propane for the winter.

 

 

NULL


 

Download Propane_usage-.mw

On the example of a manipulator with three degrees of freedom.
A mathematical model is created that takes into account degrees of freedom of the manipulator and the trajectory of the movement from the initial point to the final one (in the figure, the ends of the red curve). In the text of the program, these are the equations fi, i = 1..5.
Obviously, the straight line could be the simplest trajectory, but we will consider a slightly different variant. The solution of the system of equations is the coordinates of the points of the manipulator (x1, x2, x3) and (x4, x5, x6) in all trajectory. After that, knowing the lengths of the links and the coordinates of the points at each moment of time, any angles of the manipulator are calculated. The same selected trajectory is reproduced from these angles. The possible angles are displayed by black color.
All the work on creating a mathematical model and calculating the angles can be done without the manipulator itself, is sufficient to have only the instruction with technical characteristics.
To display some angles, the procedure created by vv is used.
MAN_2.mw

This post is devoted to the rigorous proof of Miquel's five circles theorem, which I learned about from this question. The proof is essentially very simple and takes only 15 lines of code. The figure below, in which all the labels coincide with the corresponding names in the code, illustrates the basic ideas of the code. First, we symbolically define common points of intersection of blue circles with a red unit circle  (these parameters  s1 .. s5  are the polar coordinates of these points). All other parameters of this configuration can be expressed through them. Then we find the centers  M  and  N  of two circles. Then we find the coordinates of the point  K  from the condition that  CK  is perpendicular to  MN . Then we find the point  and using the result obtained, we easily find the coordinates  of all the points  A1 .. A5. Then we find the coordinates of the point   P  as the point of intersection of the lines  A1A2  and  A3A4 . Finally, we verify that the point  P  lies on a circle with center at the point  N , which completes the proof.

                      

 

Below - the code of the proof. Note that the code does not use any special (in particular geometric) packages, only commands from the Maple kernel. I usually try any geometric problems to solve in this style, it is more reliable,  and often shorter.

restart;
t1:=s1/2+s2/2: t2:=s2/2+s3/2:
M:=[cos(t1),sin(t1)]: N:=[cos(t2),sin(t2)]:
C:=[cos(s2),sin(s2)]: K:=(1-t)*~M+t*~N:
CK:=K-C: MN:=M-N:
t0:=simplify(solve(CK[1]*MN[1]+CK[2]*MN[2]=0, t)):
E:=combine(simplify(C+2*eval(CK,t=t0))):
s0:=s5-2*Pi: s6:=s1+2*Pi:
assign(seq(A||i=eval(E,[s2=s||i,s1=s||(i-1),s3=s||(i+1)]), i=1..5)):
Dist:=(p,q)->sqrt((p[1]-q[1])^2+(p[2]-q[2])^2):
LineEq:=(P,Q)->(y-P[2])*(Q[1]-P[1])=(x-P[1])*(Q[2]-P[2]):
Line1:=LineEq(A1,A2):
Line2:=LineEq(A3,A4):
P:=combine(simplify(solve({Line1,Line2},[x,y])))[]:
Circle:=(x-N[1])^2+(y-N[2])^2-Dist(N,C)^2:
is(eval(Circle, P)=0);  
# The final result

                                                                    true


It may seem that this proof is easy to repeat manually. But this is not so. Maple brilliantly coped with very cumbersome trigonometric transformations. Look at the coordinates of point  , expressed through the initial parameters  s1 .. s5 :

simplify(eval([x,y], P));  # The coordinates of the point  P

  

  

 

ProofMiquel.mw

My September 9, 2016, blog post ("Next Number" Puzzles) pointed out the meaninglessness of the typical "next-number" puzzle. It did this by showing that two such puzzles in the STICKELERS column by Terry Stickels had more than one solution. In addition to the solution proposed in the column, another was found in a polynomial that interpolated the given members of the sequence. Of course, the very nature of the question "What is the next number?" is absurd because the next number could be anything. At best, such puzzles should require finding a pattern for the given sequence, admitting that there need not be a unique pattern.

The STICKELERS column continued to publish additional "next-number" puzzles, now no longer of interest. However, the remarkable puzzle of December 30, 2017, caused me to pull from the debris on my retirement desk the puzzle of July 15, 2017, a puzzle I had relegated to the accumulating dust thereon.

The members of the given sequence appear across the top of the following table that reproduces the graphic used to provide the solution.

It turns out that the pattern in the graphic can be expressed as 100 – (-1)k k(k+1)/2, k=0,…, a pattern Maple helped find. By the techniques in my earlier blog, an alternate pattern is expressed by the polynomial

which interpolates the nodes (1, 100), (2, 101) ... so that f(8) = -992.

The most recent puzzle consists of the sequence members 0, 1, 8, 11, 69, 88; the next number is given as 96 because these are strobogrammatic numbers, numbers that read the same upside down. Wow! A sequence with apparently no mathematical structure! Is the pattern unique? Well, it yields to the polynomial

which can also be expressed as

Hence, g(x) is an integer for any nonnegative integer x, and g(6) = -401, definitely not a strobogrammatic number. However, I do have a faint recollection that one of Terry's "next-number" puzzles had a pattern that did not yield to interpolation. Unfortunately, the dust on my desk has not yielded it up.
 

A few days ago, I drew attention to the question in which OP talked about the generation of triangles in a plane, for which the lengths of all sides, the area and radius of the inscribed circle are integers. In addition, all vertices must have different integer coordinates (6 different integers), the lengths of all sides are different and the triangles should not be rectangular. I prepared the answer to this question, but the question disappeared somewhere, so I designed my answer as a separate post.

The triangles in the plane, for which the lengths of all sides and the area  are integers, are called as Heronian triangles. See this very interesting article in the wiki about such triangles
https://en.wikipedia.org/wiki/Integer_triangle#Heronian_triangles

The procedure finds all triangles (with the fulfillment of all conditions above), for which the lengths of the two sides are in the range  N1 .. N2 . The left side of the range is an optional parameter (by default  N1=5). It is not recommended to take the length of the range more than 100, otherwise the operating time of the procedure will greatly increase. The procedure returns the list in which each triangle is represented by a list of  [list of coordinates of the vertices, area, radius of the inscribed circle, list of lengths of the sides]. Without loss of generality, one vertex coincides with the origin (obviously, by a shift it is easy to place it at any point). 

The procedure works as follows: one vertex at the origin, then the other two must lie on circles with integer and different radii  x^2+y^2=r^2. Using  isolve  command, we find all integer points on these circles, and then in the for loops we select the necessary triangles.


 

 

restart;
HeronianTriangles:=proc(N2::posint,N1::posint:=5)
local k, r, S, L, Ch, Dist, IsOnline, c, P, p, A, B, C, a, b, s, ABC, cc, s1, T ;
uses combinat, geometry;
if N2<N1 then error "Should be N2>=N1" fi;
if N2<34 then return [] fi;
k:=0:
for r from max(N1,5) to N2 do
S:=[isolve(x^2+y^2=r^2)];
if nops(S)>4 then k:=k+1; L[k]:=select(s->s[1]<>0 and s[2]<>0,map(t->rhs~(convert(t,list)), S)); fi;
od:
L:=convert(L, list):
if type(L[1],symbol) then return [] fi;

Ch:=combinat:-choose([$1..nops(L)], 2):
Dist:=(A::list,B::list)->simplify(sqrt((A[1]-B[1])^2+(A[2]-B[2])^2));
IsOnline:=(A::list,B::list)->`if`(A[1]*B[2]-A[2]*B[1]=0, true, false);
k:=0:
for c in Ch do
for A in L[c[1]] do
for B in L[c[2]] do
if not IsOnline(A,B) and nops({A[],B[]})=4 then if type(Dist(A,B),posint) then
 k:=k+1; P[k]:=[A,B] fi; fi;
od: od: od:
P:=convert(P, list):
if type(P[1],symbol) then return [] fi;

k:=0:
for p in P do
point('A',0,0), point('B',p[1]), point('C',p[2]);
a:=simplify(distance('A','B')); b:=simplify(distance('A','C')); c:=simplify(distance('B','C'));
s:=sort([a,b,c]); s1:={a,b,c};
triangle(ABC,['A','B','C']);
incircle(cc,ABC);
r:=radius(cc);
if type(r,integer) and s[3]^2<>s[1]^2+s[2]^2 and nops(s1)=3 then k:=k+1; T[k]:=[[[0,0],p[]],area(ABC),r, [a,b,c]] fi;
od:
T:=convert(T,list);
if type(T[1],symbol) then return [] fi;
T;
end proc:

Examples of use of the procedure  HeronianTriangles

T:=HeronianTriangles(100): # All the Geronian triangles, whose lengths of two sides do not exceed 100
nops(T);

256

(1)

Tp:=select(p->p[1,2,1]>0 and p[1,2,2]>0 and p[1,3,1]>0 and p[1,3,2]>0, T);

[[[[0, 0], [16, 30], [28, 21]], 252, 6, [34, 35, 15]], [[[0, 0], [30, 16], [21, 28]], 252, 6, [34, 35, 15]], [[[0, 0], [21, 28], [15, 36]], 168, 4, [35, 39, 10]], [[[0, 0], [28, 21], [36, 15]], 168, 4, [35, 39, 10]], [[[0, 0], [27, 36], [13, 84]], 900, 10, [45, 85, 50]], [[[0, 0], [36, 27], [84, 13]], 900, 10, [45, 85, 50]], [[[0, 0], [33, 44], [48, 36]], 462, 7, [55, 60, 17]], [[[0, 0], [44, 33], [36, 48]], 462, 7, [55, 60, 17]], [[[0, 0], [33, 44], [96, 28]], 1650, 15, [55, 100, 65]], [[[0, 0], [44, 33], [28, 96]], 1650, 15, [55, 100, 65]], [[[0, 0], [16, 63], [72, 21]], 2100, 20, [65, 75, 70]], [[[0, 0], [63, 16], [21, 72]], 2100, 20, [65, 75, 70]], [[[0, 0], [39, 52], [18, 80]], 1092, 12, [65, 82, 35]], [[[0, 0], [52, 39], [80, 18]], 1092, 12, [65, 82, 35]], [[[0, 0], [32, 60], [56, 42]], 1008, 12, [68, 70, 30]], [[[0, 0], [60, 32], [42, 56]], 1008, 12, [68, 70, 30]], [[[0, 0], [42, 56], [30, 72]], 672, 8, [70, 78, 20]], [[[0, 0], [56, 42], [72, 30]], 672, 8, [70, 78, 20]]]

(2)

Tr:=map(p->p+[2,1],Tp[1,1]);
with(geometry):
point(A,Tr[1]), point(B,Tr[2]), point(C,Tr[3]):
triangle(ABC,[A,B,C]):
simplify(distance(A,B)), simplify(distance(A,C)), simplify(distance(B,C));
local O:
incircle(c,ABC, centername=O):
draw([A,B,C, ABC, c(color=blue)], color=red, thickness=2, symbol=solidcircle, tickmarks = [spacing(1)$2], gridlines, scaling=constrained, view=[0..31,0..33], size=[800,550], printtext=true, font=[times, 18], axesfont=[times, 10]);

[[2, 1], [18, 31], [30, 22]]

 

34, 35, 15

 

 



Examples of triangles with longer sides

T:=HeronianTriangles(1000,980):  # All the Geronian triangles, whose lengths of two sides lie in the range  980..1000
nops(T);

56

(3)

Tp:=select(p->p[1,2,1]>0 and p[1,2,2]>0 and p[1,3,1]>0 and p[1,3,2]>0, T);  # Triangles lying in the first quarter x>0, y>0
nops(%);

[[[[0, 0], [540, 819], [680, 714]], 85680, 80, [981, 986, 175]], [[[0, 0], [819, 540], [714, 680]], 85680, 80, [981, 986, 175]], [[[0, 0], [216, 960], [600, 800]], 201600, 168, [984, 1000, 416]], [[[0, 0], [960, 216], [800, 600]], 201600, 168, [984, 1000, 416]], [[[0, 0], [380, 912], [324, 945]], 31806, 31, [988, 999, 65]], [[[0, 0], [912, 380], [945, 324]], 31806, 31, [988, 999, 65]], [[[0, 0], [594, 792], [945, 324]], 277992, 216, [990, 999, 585]], [[[0, 0], [792, 594], [324, 945]], 277992, 216, [990, 999, 585]]]

 

8

(4)

 


 

Download Integer_Triangle1.mw

Edit.

Implementation of Maple apps for the creation of mathematical exercises in
engineering

In this research work has allowed to show the implementation of applications developed in the Maple software for the creation of mathematical exercises given the different levels of education whether basic or higher.
For the majority of teachers in this area, it seems very difficult to implement apps in Maple; that is why we show the creation of exercises easily and permanently. The purpose is to get teachers from our institutions to use applications ready to be evaluated in the classroom. The results of these apps (applications with components made in Maple) are supported on mobile devices such as tablets and / or laptops and taken to the cloud to be executed online from any computer. The generation of patterns is a very important alternative leaving aside random numbers, which would allow us to lose results
onscreen. With this; Our teachers in schools or universities would evaluate their students in parallel on the blackboard without losing the results of any student and thus achieve the competencies proposed in the learning sessions.
In these apps would be the algorithms for future research updates and integrated with systems in content management. Therefore what we show here is extremely important for the evaluation on the blackboard in bulk to students without losing any scientific criteria.

FAST_UNT_2018.mw

FAST_UNT_2018.pdf

Lenin Araujo Castillo

Ambasador of Maple

 

In the beginning, Maple had indexed names, entered as x[abc]; as early as Maple V Release 4 (mid 1990s), this would display as xabc. So, x[1] could be used as x1, a subscripted variable; but assigning a value to x1 created a table whose name was x. This had, and still has, undesirable side effects. See Table 0 for an illustration in which an indexed variable is assigned a value, and then the name of the concomitant table is also assigned a value. The original indexed name is destroyed by these steps.
 

 

At one time this quirk could break commands such as dsolve. I don't know if it still does, but it's a usage that those "in the know" avoid. For other users, this was a problem that cried out for a solution. And Maplesoft did provide such a solution by going nuclear - it invented the Atomic Variable, which subsumed the subscript issue by solving a larger problem.

The larger problem is this: Arbitrary collections of symbols are not necessarily valid Maple names. For example, the expression  is not a valid name, and cannot appear on the left of an assignment operator. Values cannot be assigned to it. The Atomic solution locks such symbols together into a valid name originally called an Atomic Identifier but now called an Atomic Variable. Ah, so then xcan be either an indexed name (table entry) or a non-indexed literal name (Atomic Variable). By solving the bigger problem of creating assignable names, Maplesoft solved the smaller problem of subscripts by allowing literal subscripts to be Atomic Variables.

It is only in Maple 2017 that all vestiges of "Identifier" have disappeared, replaced by "Variable" throughout. The earliest appearance I can trace for the Atomic Identifier is in Maple 11, but it might have existed in Maple 10. Since Maple 11, help for the Atomic Identifier is found on the page 

 

In Maple 17 this help could be obtained by executing help("AtomicIdentifier"). In Maple 2017, a help page for AtomicVariables exists.

In Maple 17, construction of these Atomic things changed, and a setting was introduced to make writing literal subscripts "simpler." With two settings and two outcomes for a "subscripted variable" (either indexed or non-indexed), it might be useful to see the meaning of "simpler," as detailed in the worksheet AfterMath.mw.

Hi,

2 examples to explore components to illustrated Fractals
 

NULL

Flocon de VonKoch

 

 

 

NULL

NULL

NULL

NULL

 

 

``


 

Download AppliFloconVonKoch.mw

It passed through my mind it would be interesting to collect the links to the most relevant Mapleprimes posts about Quantum Mechanics using the Physics package of the last couple of years, to have them all accessible from one place. These posts give an idea of what kind of computation is already doable in quantum mechanics, how close is the worksheet input to what we write with paper and pencil, and how close is the typesetting of the output to what we see in textbooks.

At the end of each page linked below, you will see another link to download the corresponding worksheet, that you can open using Maple (say the current version or the version 1 or 2 years ago).

This other set of three consecutive posts develops one problem split into three parts:

This other link is interesting as a quick and compact entry point to the use of the Physics package:

There is an equivalent set of Mapleprimes posts illustrating the Physics package tackling problems in General Relativity, collecting them is for one other time.

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

December 2017: This is, perhaps, one of the most complicated computations done in this area using the Physics package. To the best of my knowledge never before performed on a computer algebra worksheet. It is exciting to present a computation like this one. At the end the corresponding worksheet is linked so that it can be downloaded and the sections be opened, the computation be reproduced. There is also a link to a pdf with everything open.  Special thanks to Pascal Szriftgiser for bringing this problem. To reproduce the computations below, please update the Physics library with the one distributed from the Maplesoft R&D Physics webpage.

June 17, 2020: updated taking advantage of new features of Maple 2020.1 and Physics Updates v.705. Submitted to arxiv.org

January 25, 2021: updated in the arXiv and submitted for publication in Computer Physics Communications

 

 

Quantum Runge-Lenz Vector and the Hydrogen Atom,

the hidden SO(4) symmetry using Computer Algebra

 

Pascal Szriftgiser1 and Edgardo S. Cheb-Terrab2 

(1) University of Lille, CNRS, UMR 8523 - PhLAM - Physique des Lasers, Atomes et Molécules, F-59000 Lille, France

(2) Maplesoft

NULL

 

Abstract

 

Pauli first noticed the hidden SO(4) symmetry for the Hydrogen atom in the early stages of quantum mechanics [1]. Departing from that symmetry, one can recover the spectrum of a spinless hydrogen atom and the degeneracy of its states without explicitly solving Schrödinger's equation [2]. In this paper, we derive that SO(4) symmetry and spectrum using a computer algebra system (CAS). While this problem is well known [3, 4], its solution involves several steps of manipulating expressions with tensorial quantum operators, simplifying them by taking into account a combination of commutator rules and Einstein's sum rule for repeated indices. Therefore, it is an excellent model to test the current status of CAS concerning this kind of quantum-and-tensor-algebra computations. Generally speaking, when capable, CAS can significantly help with manipulations that, like non-commutative tensor calculus subject to algebra rules, are tedious, time-consuming and error-prone. The presentation also shows a pattern of computer algebra operations that can be useful for systematically tackling more complicated symbolic problems of this kind.

 

Introduction

 

The primary purpose of this work is to derive, step-by-step, the SO(4) symmetry of the Hydrogen atom and its spectrum using a computer algebra system (CAS). To the best of our knowledge, such a derivation using symbolic computation has not been shown before. Part of the goal was also to see whether this computation can be performed entering only the main definition formulas, followed by only simplification commands, and without using previous knowledge of the result. The intricacy of this problem is in the symbolic manipulation and simplification of expressions involving noncommutative quantum tensor operators. The simplifications need to take into account commutator rules, symmetries under permutation of indices of tensorial subexpressions, and use Einstein's sum rule for repeated indices.

We performed the derivation using the Maple 2020 system with the Maplesoft Physics Updates v.705. Generally speaking, the default computational domain of CAS doesn't include tensors, noncommutative operators nor related simplifications. On the other hand, the Maple system is distributed with a Physics package that extends that default domain to include those objects and related operations. Physics includes a Simplify command that takes into account custom algebra rules and the sum rule for repeated indices, and uses tensor-simplification algorithms [5] extended to the noncommutative domain.

 

A note about notation: when working with a CAS, besides the expectation of achieving a correct result for a complicated symbolic calculation, readability is also an issue. It is desired that one be able to enter the definition formulas and computational steps to be performed (the input, preceded by a prompt >, displayed in black) in a way that resembles as closely as possible their paper and pencil representation, and that the results (the output, computed by Maple, displayed in blue) use textbook mathematical-physics notation. The Physics package implements such dedicated typesetting. In what follows, within text and in the output, noncommutative objects are displayed using a different color, e.g. H, vectors and tensor indices are displayed the standard way, as in `#mover(mi("L",mathcolor = "olive"),mo("&rarr;"))`, and L[q], and commutators are displayed with a minus subscript, e.g. "[H,L[q]][-]". Although the Maple system allows for providing dedicated typesetting also for the input, we preferred to keep visible the Maple input syntax, allowing for comparison with paper and pencil notation. We collected the names of the commands used and a one line description for them in an Appendix at the end. Maple also implements the concept of inert representations of computations, which are activated only when desired. We use this feature in several places. Inert computations are entered by preceding the command with % and are displayed in grey. Finally, as is usual in CAS, every output has an equation label, which we use throughout the presentation to refer to previous intermediate results.

 

In Sec.1, we recall the standard formulation of the problem and present the computational goal, which is the derivation of the formulas representing the SO(4) symmetry and related spectrum.

 

In Sec.2, we set tensorial non-commutative operators representing position and linear and angular momentum, respectively X[a], p[a] and L[a], their commutation rules used as departure point, and the form of the quantum Hamiltonian H. We also derive a few related identities used in the sections that follow.

 

In Sec.3, we derive the conservation of both angular momentum and the Runge-Lenz quantum operator, respectively "[H,L[q]][-]=0" and "[H,Z[k]][-]=0". Taking advantage of the differentialoperators functionality in the Physics package, we perform the derivation exploring two equivalent approaches; first using only a symbolic tensor representation p[j] of the momentum operator, then using an explicit differential operator representation for it in configuration space, p[j] = -i*`&hbar;`*`&PartialD;`[j].  With the first approach, expressions are simplified only using the departing commutation rules and Einstein's sum rule for repeated indices. Using the second approach, the problem is additionally transformed into one where the differentiation operators are applied explicitly to a test function G(X). Presenting both approaches is of potential interest as it offers two partly independent methods for performing the same computation, which is helpful to provide confidence on in the results when unknown, a relevant issue when using computer algebra.

 

In Sec. 4, we derive %Commutator(L[m], Z[n]) = I*`&hbar;`*`&epsilon;`[m, n, u]*Z[u] and show that the classical relation between angular momentum and the Runge-Lenz vectors,  "L *"`#mover(mi("Z"),mo("&rarr;"))` = 0, due to the orbital momentum being perpendicular to the elliptic plane of motion while the Runge-Lenz vector lies in that plane, still holds in quantum mechanics, where the components of these quantum vector operators do not commute but "L *"`#mover(mi("Z",mathcolor = "olive"),mo("&rarr;"))` = "(Z) *"`#mover(mi("L",mathcolor = "olive"),mo("&rarr;"))` = 0.

 

In Sec. 5, we derive "[Z[a],Z[b]][-]=-(2 i `&hbar;` `&epsilon;`[a,b,c] (H L[c]))/`m__e`" using the two alternative approaches described for Sec.3.

In Sec. 6, we derive the well-known formula for the square of the Runge-Lenz vector, Z[k]^2 = 2*H*(`&hbar;`^2+L[a]^2)/m__e+kappa^2.

 

Finally, in Sec. 7, we use the SO(4) algebra derived in the previous sections to obtain the spectrum of the Hydrogen atom. Following the literature, this approach is limited to the bound states for which the energy is negative.

 

Some concluding remarks are presented at the end, and input syntax details are summarized in an Appendix.

 

1. The hidden SO(4) symmetry of the Hydrogen atom

 

 

Let's consider the Hydrogen atom and its Hamiltonian

H = LinearAlgebra[Norm](`#mover(mi("p"),mo("&rarr;"))`)^2/(2*m__e)-kappa/r,

 

where `#mover(mi("p"),mo("&rarr;"))`is the electron momentum, m__e its mass, κ a real positive constant, r = `&equiv;`(LinearAlgebra[Norm](`#mover(mi("r"),mo("&rarr;"))`), sqrt(X[a]^2)) the distance of the electron from the proton located at the origin, and X[a] is its tensorial representation with components ["x, y,z]". We assume that the proton's mass is infinite. The electron and nucleus spin are not taken into account. Classically, from the potential -kappa/r, one can derive a central force `#mover(mi("F"),mo("&rarr;"))` = -kappa*`#mover(mi("r"),mo("&and;"))`/r^2 that drives the electron's motion. Introducing the angular momentum

 

`#mover(mi("L"),mo("&rarr;"))` = `&x`(`#mover(mi("r"),mo("&rarr;"))`, `#mover(mi("p"),mo("&rarr;"))`),

 

one can further define the Runge-Lenz vector `#mover(mi("Z"),mo("&rarr;"))`

 

"Z=1/(`m__e`) (L)*(p)+kappa ( r)/r."

 

It is well known that `#mover(mi("Z"),mo("&rarr;"))` is a constant of the motion, i.e. diff(`#mover(mi("Z"),mo("&rarr;"))`(t), t) = 0. Switching to Quantum Mechanics, this condition reads

 

%Commutator(H, Z_) = 0.

 

where, for hermiticity purpose, the expression of `#mover(mi("Z",mathcolor = "olive"),mo("&rarr;"))` must be symmetrized

 

`#mover(mi("Z",mathcolor = "olive"),mo("&rarr;"))` = (`&x`(`#mover(mi("L",mathcolor = "olive"),mo("&rarr;"))`, `#mover(mi("p",mathcolor = "olive"),mo("&rarr;"))`)-`&x`(`#mover(mi("p",mathcolor = "olive"),mo("&rarr;"))`, `#mover(mi("L",mathcolor = "olive"),mo("&rarr;"))`))/(2*m__e)+kappa*`#mover(mi("r",mathcolor = "olive"),mo("&rarr;"))`/r.

 

In what follows, departing from the Hamiltonian H, the basic commutation rules between position`#mover(mi("r",mathcolor = "olive"),mo("&rarr;"))`, momentum `#mover(mi("p",mathcolor = "olive"),mo("&rarr;"))` and angular momentum `#mover(mi("L",mathcolor = "olive"),mo("&rarr;"))` in tensor notation, we derive the following commutation rules between the quantum Hamiltonian, angular momentum and Runge-Lenz vector `#mover(mi("Z",mathcolor = "olive"),mo("&rarr;"))`

 

 

"[H,L[n]][-]"

=

0

"[H,Z[n]][-]"

=

0

" [L[m],Z[n]][-]"

=

I*`&hbar;`*`&epsilon;`[m, n, o]*Z[o]

" [Z[m],Z[n]][-]"

=

-(2*(I*`&hbar;`/m__e))*H*`&epsilon;`[m, n, o]*L[o]

 

 

Since H commutes with both `#mover(mi("L",mathcolor = "olive"),mo("&rarr;"))`NULL and `#mover(mi("Z",mathcolor = "olive"),mo("&rarr;"))`, defining

 

"`M__n`=sqrt(-(`m__e`)/(2 H)) `Z__n`,"

these commutation rules can be rewritten as

 

"[L[m],L[n]][-]"

=

I*`&hbar;`*`&epsilon;`[m, n, o]*L[o]

" [L[m],M[n]][-]"

=

I*`&hbar;`*`&epsilon;`[m, n, o]*M[o]

"[M[m],M[n]][-]"

=

I*`&hbar;`*`&epsilon;`[m, n, o]*L[o]

 

 

  

This set constitutes the Lie algebra of the SO(4) group.

  

 

2. Setting the problem, commutation rules and useful identities

   

3. Commutation rules between the Hamiltonian and each of the angular momentum and Runge-Lenz tensors

   

4. Commutation rules between the angular momentum L[q]and the Runge-Lenz Z[k]tensors

   

5.  Commutation rules between the components of the Runge-Lenz tensor

   

6. The square of the norm of the Runge-Lenz vector

   

7. The atomic hydrogen spectrum

   

Conclusions

 

 

In this presentation, we derived, step-by-step, the SO(4) symmetry of the Hydrogen atom and its spectrum using the symbolic computer algebra Maple system. The derivation was performed without departing from the results, entering only the main definition formulas in eqs. (1), (2) and (5), followed by using a few simplification commands - mainly Simplify, SortProducts and SubstituteTensor - and a handful of Maple basic commands, subs, lhs, rhs and isolate. The computational path that was used to get the results of sections 2 to 7 is not unique. Instead of searching for the shortest path, we prioritized clarity and illustration of the techniques that can be used to crack problems like this one.

This problem is mainly about simplifying expressions using two different techniques. First, expressions with noncommutative operands in products need reduction with respect to the commutator algebra rules that have been set. Second, products of tensorial operators require simplification using the sum rule for repeated indices and the symmetries of tensorial subexpressions. Those techniques, which are part of the Maple Physics simplifier, together with the SortProducts and SubstituteTensor commands for sorting the operands in products to apply tensorial identities, sufficed. The derivations were performed in a reasonably small number of steps.

Two different computational strategies - with and without differential operators - were used in sections 3 and 5, showing an approach for verifying results, a relevant issue in general when performing complicated algebraic manipulations. The Maple Physics ability to handle differential operators as noncommutative operands in products (as frequently done in paper and pencil computations) facilitates readability and ease in entering the computations. The complexity of those operations is then handled by one Physics:-Library command, ApplyProductsOfDifferentialOperators (see eqs. (47) and (83)).

Besides the Maple Physics ability to handle noncommutative tensor operators and simplify such operators using commutator algebra rules, it is interesting to note: a) the ability of the system to factorize expressions involving products of noncommutative operands (see eqs. (90) and (108)) and b) the extension of the algorithms for simplifying tensorial expressions [5] to the noncommutativity domain, used throughout this presentation.

It is also worth mentioning how equation labels can reduce the whole computation to entering the main definitions, followed by applying a few commands to equation labels. That approach helps to reduce the chance of typographical errors to a very strict minimum. Likewise, the fact that commands and equations distribute over each other allows cumbersome manipulations to be performed in simple ways, as done, for instance, in eqs. (8), (9) and (13).

Finally, it was significantly helpful for us to have the typesetting of results using standard mathematical physics notation, as shown in the presentation above.

 

Appendix

 

 

In this presentation, the input lines are preceded by a prompt > and the commands used are of three kinds: some basic Maple manipulation commands, the main Physics package commands to set things and simplify expressions, and two commands of the Physics:-Library to perform specialized, convenient, operations in expressions.

 

The basic Maple commands used

 

• 

interface is used once at the beginning to set the letter used to represent the imaginary unit (default is I but we used i).

• 

isolate is used in several places to isolate a variable in an expression, for example isolating x in a*x+b = 0 results in x = -b/a

• 

lhs and rhs respectively get the left-hand side Aand right-hand side Bof an equation A = B

• 

subs substitutes the left-hand side of an equation by the righ-hand side in a given target, for example subs(A = B, A+C) results in B+C

• 

@ is used to compose commands. So(`@`(A, B))(x) is the same as A(B(x)). This command is useful to express an abstract combo of manipulations, for example as in (108) ≡ lhs = `@`(Factor, rhs).

 

The Physics commands used

 

• 

Setup is used to set algebra rules as well as the dimension of space, type of metric, and conventions as the kind of letter used to represent indices.

• 

Commutator computes the commutator between two objects using the algebra rules set using Setup. If no rules are known to the system, it outputs a representation for the commutator that the system understands.

• 

CompactDisplay is used to avoid redundant display of the functionality of a function.

• 

d_[n] represents the `&PartialD;`[n] tensorial differential operator.

• 

Define is used to define tensors, with or without specifying its components.

• 

Dagger  computes the Hermitian transpose of an expression.

• 

Normal, Expand, Factor respectively normalizes, expands and factorizes expressions that involve products of noncommutative operands.

• 

Simplify performs simplification of tensorial expressions involving products of noncommutative factors taking into account Einstein's sum rule for repeated indices, symmetries of the indices of tensorial subexpressions and custom commutator algebra rules.

• 

SortProducts uses the commutation rules set using Setup to sort the non-commutative operands of a product in an indicated ordering.

 

The Physics:-Library commands used

 

• 

Library:-ApplyProductsOfDifferentialOperators applies the differential operators found in a product to the product operands that appear to its right. For example, applying this command to  p*V(X)*m__e results in m__e*p(V(X))

• 

Library:-EqualizeRepeatedIndices equalizes the repeated indices in the terms of a sum, so for instance applying this command to L[a]^2+L[b]^2 results in 2*L[a]^2

 

References

 

[1] W. Pauli, "On the hydrogen spectrum from the standpoint of the new quantum mechanics,” Z. Phys. 36, 336–363 (1926)

[2] S. Weinberg, "Lectures on Quantum Mechanics, second edition, Cambridge University Press," 2015.

[3] Veronika Gáliková, Samuel Kováčik, and Peter Prešnajder, "Laplace-Runge-Lenz vector in quantum mechanics in noncommutative space", J. Math. Phys. 54, 122106 (2013)

[4] Castro, P.G., Kullock, R. "Physics of the so__q(4) hydrogen atom". Theor. Math. Phys. 185, 1678–1684 (2015).

[5] L. R. U. Manssur, R. Portugal, and B. F. Svaiter, "Group-Theoretic Approach for Symbolic Tensor Manipulation," International Journal of Modern Physics C, Vol. 13, No. 07, pp. 859-879 (2002).

 

Download Hidden_SO4_symmetry_of_the_hydrogen_atom.mw

Download Hidden_SO4_symmetry_submitted_to_CPC.pdf (all sections open)


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

hi guys....new image that I am very proud of....utilzing the number theoretic argument λ (n)

 

 

My co-author and I recently published the 3rd edition of our finite element book1 utilizing routines written with MAPLE. In this latest edition, we include a chapter on the meshless method. The meshless method is a unique numerical method for solving PDEs. The finite element method requires the establishment of a mesh associated with node points. Consideration must be given in establishing a good mesh (and minimizing the bandwidth associated with node numbering). The meshless method does not require a mesh to connect nodes. The following excerpt describes the application of the meshless method for a simple 1-D heat transfer simulation using six nodes.

Consider the 1-D expression for heat transfer in a bar defined by the relation2

     (1)

where the 1-D domain is bounded by 0 ≤ xL. The exact solution to this problem is

     (2)

with the exact derivative of the temperature given by

     (3)

 

In order to solve the 1-D problem, a multiquadric (MQ) radial basis function (RBF) is used 

     (4)

where r(x, xj) is the radial (Euclidean) distance from the expansion point (xj) to any point (x) , c is a shape parameter that controls the flatness of the RBF and is set by the user, and n is an integer. With n = 1, we retrieve the inverse multiquadric

     (5)

that will be used to solve Eq. (1). Other types of RBFs are available; the MQ is accurate and popular.

 

A global expansion for the 1-D temperature can be expressed as

     (6)

with the second derivative of the temperature given as

     (7)

Introducing the RBF expansion for the terms in the governing equation, and collocating at the interior points, we obtain

     (8)

At the boundaries, we collocate the RBF expansion to impose the boundary conditions

     (9)

Defining the operator

     (10)

we can now assemble into a fully populated matrix as,

     (11)

 

The solutions obtained using finite difference, finite volume, finite element, boundary element, and the meshless method are listed in Table 1 for 6 equally spaced nodes3 with To = 15 and TL = 25, and L = 1. The interior nodes do not have to be uniformly spaced.

Table 1. Comparison of errors for interior temperatures i = 2,3,…N-1

 

The Maple code listing follows:

> restart:
   with(LinearAlgebra):with(plots):

# MESHLESS METHOD SOLUTION USING MULTIQUADRIC RADIAL BASIS
FUNCTIONS (RBF) il:=6:To:=15:TL:=25:L:=1:
>   x:=[0,1/5,2/5,3/5,4/5,1]:
>   S:=1000:n:=1:dx:=1/(il-1):
>   C:=Array(1..il,1..il):phi:=Array(1..il,1..il):d2phi:=Array(1..il,1..il):
b:=Vector(1..il):TM:=Vector(1..il):alpha:=Vector(1..il):
for i from 1 to il do
   for j from 1 to il do
      phi[i,j]:=(1+(x[i]-x[j])^2/(S*dx^2))^(n-3/2):
      d2phi[i,j]:=3*((x[j]-x[i])/20)^2/(4*((x[j]-x[i])^2/40+1)^(5/2) )-1/(40*((x[j]-x[i])^2/40+1)^(3/2)):
   end do:
end do:
>   for i from 2 to il-1 do    
>       for j from 1 to il do
>         C[i,j]:=d2phi[i,j]+phi[i,j];
            b[i]:=-x[i];
>         C[1,j]:=phi[1,j];
           C[il,j]:=phi[il,j];
         end do:
      end do:
      b[1]:=To:b[il]:=TL:
> #ConditionNumber(C);
>   alpha:=LinearSolve(convert(C,Matrix),b):
TM[1]:=To:TM[6]:=TL:
for i from 2 to il-1 do
   for j from 1 to il do
>         TM[i]:=TM[i]+alpha[j]*(1+(x[i]-x[j])^2/(S*dx^2))^(n-3/2);
 >     end do:
>   end do:
     evalf(TM);

                     

> TE:=To*cos(xx)+(TL+L-To*cos(L))/sin(L)*sin(xx)-xx:
> TE:=subs(TE):
> TE:=plot(TE,xx=0..1,color=blue,legend="Exact",thickness=3):
> MEM:=[seq([subs(x[i]),subs(TM[i])],i=1..6)]:
> T:=plots[pointplot](MEM,style=line,color=red,legend="MEM", thickness=3): 
  MEM:=plots[pointplot](MEM,color=red,legend="MEM",symbol=box, symbolsize=15):

>  plots[display](TE,MEM,T,axes=BOXED,title="Solution - MEM");

              

 

Additional examples for two-dimensional domains are described in the text, along with a chapter on the boundary element method. The meshless method is an interesting numerical approach that belongs to the family of weighted residual techniques. The matrix condition number is on the order of 1010 and can give surprisingly good results – however, the solution can fluctuate when repeatedly executed, eventually returning to the nearly correct solution; this is not an issue when using local assembly instead of the global assemble performed here4. The method can be used to form hybrid schemes, e.g., a finite element method can easily be linked with a meshless method to solve a secondary system of equations for problems involving large domains. Results are not sensitive to the location of the nodes; a random placement of points gives qualitatively similar results as a uniform placement.

Just over a year ago, someone asked me if Maple could help them pick names for their family gift exchange, because they were fed up with trying to find a solution by hand that met all their requirements. I knew it could be done, of course, and I spent some time (and at least one family dinner conversation) talking about how to do it. There wasn’t enough time to help my friend last year, but I dusted off my ideas, and my somewhat rusty Maple programming skills, and put something together for this year.

The problem, as stated to me, was “Assign everyone in the group the name of someone else in the group (the person they will buy a present for), with the restriction that no one can be assigned their partner.”

I decided to generalize a bit so that you can specify more than one person in the “do not pick” list for each individual, and the restrictions do not have to be reciprocal. That way, you can use it with rules like “parents cannot pick their children”, or “Elizabeth got Martin two years running, so she can’t pick him again this year”.

Ultimately I went with a “guess and check” approach. For each person, pick a name from the pool of suitable candidates (excluding themselves, anyone on their “do not pick” list, and anyone who has been picked already). Keep assigning names until either everyone has a name, or you end up in a situation where you can’t give someone a name. This can happen, for instance, if Todd is the last name, and the only unmatched name is Catherine, and Todd cannot pick Catherine. If that happens, I tossed all the names back into the virtual hat, gave it a good shake (i.e. randomize()) and tried again. Not as elegant as I would have liked, but it seemed like an effective approach.

It does feel like there ought to be a “nicer” solution. Maybe using graph theory? I know that my code will get into trouble if the restrictions are such that no solution exists.  If anyone has any ideas on other/better ways to solve this problem I’d be happy to hear them (now that I’ve had the fun of solving it myself first!).  

The application can be found on the application center: Gift Exchange Helper. The name picker algorithm is in the start-up code.

Happy gift giving!

The computation of traces of products of Dirac matrices was implemented years ago - see Physics,Trace .

 

The simplification of products of Dirac matrices, however, was not. Now it is, and illustrating this new feature is the matter of this post. To reproduce the results below please update the Physics library with the one distributed at the Maplesoft R&D Physics webpage.

with(Physics)

 

First of all, when loading Physics, a frequent question is about the signature, the default is (- - - +)

Setup(signature)

[signature = `- - - +`]

(1)

This is important because the convention for the Algebra of Dirac Matrices depends on the signature. With the signatures (- - - +) as well as (+ - - -), the sign of the timelike component is 1

Library:-SignOfTimelikeComponent()

1

(2)

With the signatures (+ + + -) as well as (- + + +), the sign of the timelike component is of course -1

Library:-SignOfTimelikeComponent(`+ + + -`)

-1

(3)

The simplification of products of Dirac Matrices, illustrated below with the default signature, works fine with any of these signatures, and works without having to set a representation for the Dirac matrices -- all the results are representation-independent.

 

The examples below, however, also illustrate a new feature of Physics, for now implemented as a Library:-PerformMatrixOperations command (there is a related, also new, command, Library:-RewriteInMatrixForm, to just present the underlying matrix operations, without performing them). To illustrate this other new functionality , set a representation for the Dirac matrices, say the standard one

 

Setup(Dgamma = standard, math = true)

`* Partial match of  'Physics:-Dgamma' against keyword 'Dgammarepresentation'`

 

`* Partial match of  'math' against keyword 'mathematicalnotation'`

 

`Setting lowercaselatin letters to represent spinor indices `

 

`Defined Dirac gamma matrices (Dgamma) in standard representation`, gamma[1], gamma[2], gamma[3], gamma[4]

 

__________________________________________________

 

[Dgammarepresentation = standard, mathematicalnotation = true]

(4)

The four Dirac matrices are

TensorArray(Dgamma[`~mu`])

Array(%id = 18446744078360533342)

(5)

The definition of the Dirac matrices is implemented in Maple following the conventions of Landau books ([1] Quantum Electrodynamics, V4), and  does not depend on the signature, ie the form of these matrices is

"Library:-RewriteInMatrixForm(?)"

Array(%id = 18446744078360529726)

(6)

With the default signature, the space part components of  gamma[mu] change sign when compared with corresponding ones from gamma[`~mu`] while the timelike component remains unchanged

TensorArray(Dgamma[mu])

Array(%id = 18446744078565663678)

(7)

"Library:-RewriteInMatrixForm(?)"

Array(%id = 18446744078677131982)

(8)

For the default signature, the algebra of the Dirac Matrices, loaded by default when Physics is loaded, is (see page 80 of [1])

(%AntiCommutator = AntiCommutator)(Dgamma[`~mu`], Dgamma[`~nu`])

%AntiCommutator(Physics:-Dgamma[`~mu`], Physics:-Dgamma[`~nu`]) = 2*Physics:-g_[`~mu`, `~nu`]

(9)

When the sign of the timelike component of the signature is -1, we have a -1 factor on the right-hand side of (9).

 

Note as well that in (9) the right-hand side has no matrix elements. This is standard in particle physics where the computations are performed algebraically, without performing the matrix operations. For the purpose of actually performing the underlying matrix operations, however, one may want to rewrite this algebra including a 4x4 identity matrix. For that purpose, see Algebra of Dirac Matrices with an identity matrix on the right-hand side. For the purpose of this illustration, below we proceed with the algebra as shown in (9), interpreting right-hand sides as if they involve an identity matrix.

 

Verify the algebra rule by performing all the involved matrix operations

expand(%AntiCommutator(Physics[Dgamma][`~mu`], Physics[Dgamma][`~nu`]) = 2*Physics[g_][`~mu`, `~nu`])

Physics:-`*`(Physics:-Dgamma[`~mu`], Physics:-Dgamma[`~nu`])+Physics:-`*`(Physics:-Dgamma[`~nu`], Physics:-Dgamma[`~mu`]) = 2*Physics:-g_[`~mu`, `~nu`]

(10)

Note that, regarding the spacetime indices, this is a 4x4 matrix, whose elements are in turn 4x4 matrices. Compute first the external 4x4 matrix related to mu and nu

TensorArray(Physics[`*`](Physics[Dgamma][`~mu`], Physics[Dgamma][`~nu`])+Physics[`*`](Physics[Dgamma][`~nu`], Physics[Dgamma][`~mu`]) = 2*Physics[g_][`~mu`, `~nu`])

Matrix(%id = 18446744078587020822)

(11)

Perform now all the matrix operations involved in each of the elements of this 4x4 matrix

"Library:-PerformMatrixOperations(?)"

Matrix(%id = 18446744078743243942)

(12)

By eye everything checks OK.NULL

 

Consider now the following five products of Dirac matrices

e0 := Dgamma[mu]^2

Physics:-`*`(Physics:-Dgamma[mu], Physics:-Dgamma[`~mu`])

(13)

e1 := Dgamma[mu]*Dgamma[`~nu`]*Dgamma[mu]

Physics:-`*`(Physics:-Dgamma[mu], Physics:-Dgamma[`~nu`], Physics:-Dgamma[`~mu`])

(14)

e2 := Dgamma[mu]*Dgamma[`~lambda`]*Dgamma[`~nu`]*Dgamma[mu]

Physics:-`*`(Physics:-Dgamma[mu], Physics:-Dgamma[`~lambda`], Physics:-Dgamma[`~nu`], Physics:-Dgamma[`~mu`])

(15)

e3 := Dgamma[mu]*Dgamma[`~lambda`]*Dgamma[`~nu`]*Dgamma[`~rho`]*Dgamma[mu]

Physics:-`*`(Physics:-Dgamma[mu], Physics:-Dgamma[`~lambda`], Physics:-Dgamma[`~nu`], Physics:-Dgamma[`~rho`], Physics:-Dgamma[`~mu`])

(16)

e4 := Dgamma[mu]*Dgamma[`~lambda`]*Dgamma[`~nu`]*Dgamma[`~rho`]*Dgamma[`~sigma`]*Dgamma[mu]

Physics:-`*`(Physics:-Dgamma[mu], Physics:-Dgamma[`~lambda`], Physics:-Dgamma[`~nu`], Physics:-Dgamma[`~rho`], Physics:-Dgamma[`~sigma`], Physics:-Dgamma[`~mu`])

(17)

New: the simplification of these products is now implemented

e0 = Simplify(e0)

Physics:-`*`(Physics:-Dgamma[mu], Physics:-Dgamma[`~mu`]) = 4

(18)

Verify this result performing the underlying matrix operations

T := SumOverRepeatedIndices(Physics[`*`](Physics[Dgamma][mu], Physics[Dgamma][`~mu`]) = 4)

Physics:-`*`(Physics:-Dgamma[1], Physics:-Dgamma[`~1`])+Physics:-`*`(Physics:-Dgamma[2], Physics:-Dgamma[`~2`])+Physics:-`*`(Physics:-Dgamma[3], Physics:-Dgamma[`~3`])+Physics:-`*`(Physics:-Dgamma[4], Physics:-Dgamma[`~4`]) = 4

(19)

Library:-PerformMatrixOperations(T)

Matrix(%id = 18446744078553169662) = 4

(20)

The same with the other expressions

e1 = Simplify(e1)

Physics:-`*`(Physics:-Dgamma[mu], Physics:-Dgamma[`~nu`], Physics:-Dgamma[`~mu`]) = -2*Physics:-Dgamma[`~nu`]

(21)

SumOverRepeatedIndices(Physics[`*`](Physics[Dgamma][mu], Physics[Dgamma][`~nu`], Physics[Dgamma][`~mu`]) = -2*Physics[Dgamma][`~nu`])

Physics:-`*`(Physics:-Dgamma[1], Physics:-Dgamma[`~nu`], Physics:-Dgamma[`~1`])+Physics:-`*`(Physics:-Dgamma[2], Physics:-Dgamma[`~nu`], Physics:-Dgamma[`~2`])+Physics:-`*`(Physics:-Dgamma[3], Physics:-Dgamma[`~nu`], Physics:-Dgamma[`~3`])+Physics:-`*`(Physics:-Dgamma[4], Physics:-Dgamma[`~nu`], Physics:-Dgamma[`~4`]) = -2*Physics:-Dgamma[`~nu`]

(22)

T := TensorArray(Physics[`*`](Physics[Dgamma][1], Physics[Dgamma][`~nu`], Physics[Dgamma][`~1`])+Physics[`*`](Physics[Dgamma][2], Physics[Dgamma][`~nu`], Physics[Dgamma][`~2`])+Physics[`*`](Physics[Dgamma][3], Physics[Dgamma][`~nu`], Physics[Dgamma][`~3`])+Physics[`*`](Physics[Dgamma][4], Physics[Dgamma][`~nu`], Physics[Dgamma][`~4`]) = -2*Physics[Dgamma][`~nu`])

Array(%id = 18446744078695012102)

(23)

Library:-PerformMatrixOperations(T)

Array(%id = 18446744078701714238)

(24)

For e2

e2 = Simplify(e2)

Physics:-`*`(Physics:-Dgamma[mu], Physics:-Dgamma[`~lambda`], Physics:-Dgamma[`~nu`], Physics:-Dgamma[`~mu`]) = 4*Physics:-g_[`~lambda`, `~nu`]

(25)

SumOverRepeatedIndices(Physics[`*`](Physics[Dgamma][mu], Physics[Dgamma][`~lambda`], Physics[Dgamma][`~nu`], Physics[Dgamma][`~mu`]) = 4*Physics[g_][`~lambda`, `~nu`])

Physics:-`*`(Physics:-Dgamma[1], Physics:-Dgamma[`~lambda`], Physics:-Dgamma[`~nu`], Physics:-Dgamma[`~1`])+Physics:-`*`(Physics:-Dgamma[2], Physics:-Dgamma[`~lambda`], Physics:-Dgamma[`~nu`], Physics:-Dgamma[`~2`])+Physics:-`*`(Physics:-Dgamma[3], Physics:-Dgamma[`~lambda`], Physics:-Dgamma[`~nu`], Physics:-Dgamma[`~3`])+Physics:-`*`(Physics:-Dgamma[4], Physics:-Dgamma[`~lambda`], Physics:-Dgamma[`~nu`], Physics:-Dgamma[`~4`]) = 4*Physics:-g_[`~lambda`, `~nu`]

(26)

T := TensorArray(Physics[`*`](Physics[Dgamma][1], Physics[Dgamma][`~lambda`], Physics[Dgamma][`~nu`], Physics[Dgamma][`~1`])+Physics[`*`](Physics[Dgamma][2], Physics[Dgamma][`~lambda`], Physics[Dgamma][`~nu`], Physics[Dgamma][`~2`])+Physics[`*`](Physics[Dgamma][3], Physics[Dgamma][`~lambda`], Physics[Dgamma][`~nu`], Physics[Dgamma][`~3`])+Physics[`*`](Physics[Dgamma][4], Physics[Dgamma][`~lambda`], Physics[Dgamma][`~nu`], Physics[Dgamma][`~4`]) = 4*Physics[g_][`~lambda`, `~nu`])

Matrix(%id = 18446744078470204942)

(27)

Library:-PerformMatrixOperations(T)

Matrix(%id = 18446744078550068870)

(28)

For e3 we have

e3 = Simplify(e3)

Physics:-`*`(Physics:-Dgamma[mu], Physics:-Dgamma[`~lambda`], Physics:-Dgamma[`~nu`], Physics:-Dgamma[`~rho`], Physics:-Dgamma[`~mu`]) = -2*Physics:-`*`(Physics:-Dgamma[`~rho`], Physics:-Dgamma[`~nu`], Physics:-Dgamma[`~lambda`])

(29)

Verify this result,

SumOverRepeatedIndices(Physics[`*`](Physics[Dgamma][mu], Physics[Dgamma][`~lambda`], Physics[Dgamma][`~nu`], Physics[Dgamma][`~rho`], Physics[Dgamma][`~mu`]) = -2*Physics[`*`](Physics[Dgamma][`~rho`], Physics[Dgamma][`~nu`], Physics[Dgamma][`~lambda`]))

Physics:-`*`(Physics:-Dgamma[1], Physics:-Dgamma[`~lambda`], Physics:-Dgamma[`~nu`], Physics:-Dgamma[`~rho`], Physics:-Dgamma[`~1`])+Physics:-`*`(Physics:-Dgamma[2], Physics:-Dgamma[`~lambda`], Physics:-Dgamma[`~nu`], Physics:-Dgamma[`~rho`], Physics:-Dgamma[`~2`])+Physics:-`*`(Physics:-Dgamma[3], Physics:-Dgamma[`~lambda`], Physics:-Dgamma[`~nu`], Physics:-Dgamma[`~rho`], Physics:-Dgamma[`~3`])+Physics:-`*`(Physics:-Dgamma[4], Physics:-Dgamma[`~lambda`], Physics:-Dgamma[`~nu`], Physics:-Dgamma[`~rho`], Physics:-Dgamma[`~4`]) = -2*Physics:-`*`(Physics:-Dgamma[`~rho`], Physics:-Dgamma[`~nu`], Physics:-Dgamma[`~lambda`])

(30)

In this case, with three free spacetime indices lambda, nu, rho, the spacetime components form an array 4x4x4 of 64 components, each of which is a matrix equation

T := TensorArray(Physics[`*`](Physics[Dgamma][1], Physics[Dgamma][`~lambda`], Physics[Dgamma][`~nu`], Physics[Dgamma][`~rho`], Physics[Dgamma][`~1`])+Physics[`*`](Physics[Dgamma][2], Physics[Dgamma][`~lambda`], Physics[Dgamma][`~nu`], Physics[Dgamma][`~rho`], Physics[Dgamma][`~2`])+Physics[`*`](Physics[Dgamma][3], Physics[Dgamma][`~lambda`], Physics[Dgamma][`~nu`], Physics[Dgamma][`~rho`], Physics[Dgamma][`~3`])+Physics[`*`](Physics[Dgamma][4], Physics[Dgamma][`~lambda`], Physics[Dgamma][`~nu`], Physics[Dgamma][`~rho`], Physics[Dgamma][`~4`]) = -2*Physics[`*`](Physics[Dgamma][`~rho`], Physics[Dgamma][`~nu`], Physics[Dgamma][`~lambda`]))

Array(%id = 18446744078647326830)

(31)

For instance, the first element is

T[1, 1, 1]

Physics:-`*`(Physics:-Dgamma[1], Physics:-`^`(Physics:-Dgamma[`~1`], 4))+Physics:-`*`(Physics:-Dgamma[2], Physics:-`^`(Physics:-Dgamma[`~1`], 3), Physics:-Dgamma[`~2`])+Physics:-`*`(Physics:-Dgamma[3], Physics:-`^`(Physics:-Dgamma[`~1`], 3), Physics:-Dgamma[`~3`])+Physics:-`*`(Physics:-Dgamma[4], Physics:-`^`(Physics:-Dgamma[`~1`], 3), Physics:-Dgamma[`~4`]) = -2*Physics:-`^`(Physics:-Dgamma[`~1`], 3)

(32)

and it checks OK:

Library:-PerformMatrixOperations(T[1, 1, 1])

Matrix(%id = 18446744078647302614) = Matrix(%id = 18446744078647302974)

(33)

How can you test the 64 components of T all at once?

1. Compute the matrices, without displaying the whole thing, take the elements of the array and remove the indices (ie take the right-hand side); call it M

 

M := map(rhs, ArrayElems(Library:-PerformMatrixOperations(T)))

 

For instance,

M[1]

Matrix(%id = 18446744078629635726) = Matrix(%id = 18446744078629636206)

(34)

Now verify all these matrix equations at once: take the elements of the arrays on each side of the equations and verify that the are the same: we expect for output just {true}

 

map(proc (u) options operator, arrow; evalb(map(ArrayElems, u)) end proc, M)

{true}

(35)

The same for e4

e4 = Simplify(e4)

Physics:-`*`(Physics:-Dgamma[mu], Physics:-Dgamma[`~lambda`], Physics:-Dgamma[`~nu`], Physics:-Dgamma[`~rho`], Physics:-Dgamma[`~sigma`], Physics:-Dgamma[`~mu`]) = 2*Physics:-`*`(Physics:-Dgamma[`~sigma`], Physics:-Dgamma[`~lambda`], Physics:-Dgamma[`~nu`], Physics:-Dgamma[`~rho`])+2*Physics:-`*`(Physics:-Dgamma[`~rho`], Physics:-Dgamma[`~nu`], Physics:-Dgamma[`~lambda`], Physics:-Dgamma[`~sigma`])

(36)

SumOverRepeatedIndices(Physics[`*`](Physics[Dgamma][mu], Physics[Dgamma][`~lambda`], Physics[Dgamma][`~nu`], Physics[Dgamma][`~rho`], Physics[Dgamma][`~sigma`], Physics[Dgamma][`~mu`]) = 2*Physics[`*`](Physics[Dgamma][`~sigma`], Physics[Dgamma][`~lambda`], Physics[Dgamma][`~nu`], Physics[Dgamma][`~rho`])+2*Physics[`*`](Physics[Dgamma][`~rho`], Physics[Dgamma][`~nu`], Physics[Dgamma][`~lambda`], Physics[Dgamma][`~sigma`]))

Physics:-`*`(Physics:-Dgamma[1], Physics:-Dgamma[`~lambda`], Physics:-Dgamma[`~nu`], Physics:-Dgamma[`~rho`], Physics:-Dgamma[`~sigma`], Physics:-Dgamma[`~1`])+Physics:-`*`(Physics:-Dgamma[2], Physics:-Dgamma[`~lambda`], Physics:-Dgamma[`~nu`], Physics:-Dgamma[`~rho`], Physics:-Dgamma[`~sigma`], Physics:-Dgamma[`~2`])+Physics:-`*`(Physics:-Dgamma[3], Physics:-Dgamma[`~lambda`], Physics:-Dgamma[`~nu`], Physics:-Dgamma[`~rho`], Physics:-Dgamma[`~sigma`], Physics:-Dgamma[`~3`])+Physics:-`*`(Physics:-Dgamma[4], Physics:-Dgamma[`~lambda`], Physics:-Dgamma[`~nu`], Physics:-Dgamma[`~rho`], Physics:-Dgamma[`~sigma`], Physics:-Dgamma[`~4`]) = 2*Physics:-`*`(Physics:-Dgamma[`~sigma`], Physics:-Dgamma[`~lambda`], Physics:-Dgamma[`~nu`], Physics:-Dgamma[`~rho`])+2*Physics:-`*`(Physics:-Dgamma[`~rho`], Physics:-Dgamma[`~nu`], Physics:-Dgamma[`~lambda`], Physics:-Dgamma[`~sigma`])

(37)

Regarding the spacetime indices this is now an array 4x4x4x4

T := TensorArray(Physics[`*`](Physics[Dgamma][1], Physics[Dgamma][`~lambda`], Physics[Dgamma][`~nu`], Physics[Dgamma][`~rho`], Physics[Dgamma][`~sigma`], Physics[Dgamma][`~1`])+Physics[`*`](Physics[Dgamma][2], Physics[Dgamma][`~lambda`], Physics[Dgamma][`~nu`], Physics[Dgamma][`~rho`], Physics[Dgamma][`~sigma`], Physics[Dgamma][`~2`])+Physics[`*`](Physics[Dgamma][3], Physics[Dgamma][`~lambda`], Physics[Dgamma][`~nu`], Physics[Dgamma][`~rho`], Physics[Dgamma][`~sigma`], Physics[Dgamma][`~3`])+Physics[`*`](Physics[Dgamma][4], Physics[Dgamma][`~lambda`], Physics[Dgamma][`~nu`], Physics[Dgamma][`~rho`], Physics[Dgamma][`~sigma`], Physics[Dgamma][`~4`]) = 2*Physics[`*`](Physics[Dgamma][`~sigma`], Physics[Dgamma][`~lambda`], Physics[Dgamma][`~nu`], Physics[Dgamma][`~rho`])+2*Physics[`*`](Physics[Dgamma][`~rho`], Physics[Dgamma][`~nu`], Physics[Dgamma][`~lambda`], Physics[Dgamma][`~sigma`]))

Array(%id = 18446744078730196382)

(38)

For instance the first of these 256 matrix equations

T[1, 1, 1, 1]

Physics:-`*`(Physics:-Dgamma[1], Physics:-`^`(Physics:-Dgamma[`~1`], 5))+Physics:-`*`(Physics:-Dgamma[2], Physics:-`^`(Physics:-Dgamma[`~1`], 4), Physics:-Dgamma[`~2`])+Physics:-`*`(Physics:-Dgamma[3], Physics:-`^`(Physics:-Dgamma[`~1`], 4), Physics:-Dgamma[`~3`])+Physics:-`*`(Physics:-Dgamma[4], Physics:-`^`(Physics:-Dgamma[`~1`], 4), Physics:-Dgamma[`~4`]) = 4*Physics:-`^`(Physics:-Dgamma[`~1`], 4)

(39)

verifies OK:

Library:-PerformMatrixOperations(Physics[`*`](Physics[Dgamma][1], Physics[`^`](Physics[Dgamma][`~1`], 5))+Physics[`*`](Physics[Dgamma][2], Physics[`^`](Physics[Dgamma][`~1`], 4), Physics[Dgamma][`~2`])+Physics[`*`](Physics[Dgamma][3], Physics[`^`](Physics[Dgamma][`~1`], 4), Physics[Dgamma][`~3`])+Physics[`*`](Physics[Dgamma][4], Physics[`^`](Physics[Dgamma][`~1`], 4), Physics[Dgamma][`~4`]) = 4*Physics[`^`](Physics[Dgamma][`~1`], 4))

Matrix(%id = 18446744078727227382) = Matrix(%id = 18446744078727227862)

(40)

Now all the 256 matrix equations verified at once as done for e3

 

M := map(rhs, ArrayElems(Library:-PerformMatrixOperations(T)))

map(proc (u) options operator, arrow; evalb(map(ArrayElems, u)) end proc, M)

{true}

(41)

Finally, although there is more work to be done here, let's define some tensors and contract their product with these expressions involving products of Dirac matrices.

 

For example,

Define(A, B)

`Defined as tensors`

 

{A[nu], B[lambda], Physics:-Dgamma[mu], Physics:-Psigma[mu], Physics:-d_[mu], Physics:-g_[mu, nu], Physics:-KroneckerDelta[mu, nu], Physics:-LeviCivita[alpha, beta, mu, nu]}

(42)

Contract with e1 and e2 and simplify

A[nu]*e1; % = Simplify(%)

A[nu]*Physics:-`*`(Physics:-Dgamma[mu], Physics:-Dgamma[`~nu`], Physics:-Dgamma[`~mu`]) = -2*A[`~nu`]*Physics:-Dgamma[nu]

(43)

A[nu]*B[lambda]*e2; % = Simplify(%)

A[nu]*B[lambda]*Physics:-`*`(Physics:-Dgamma[mu], Physics:-Dgamma[`~lambda`], Physics:-Dgamma[`~nu`], Physics:-Dgamma[`~mu`]) = 4*B[`~nu`]*A[nu]

(44)

 


 

Download DiracMatricesAndPerformMatrixOperation.mw

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

Are you a broke university or college student, living day to day, sustaining yourself on a package of ramen noodles every day? Scared that you’re missing necessary nutrients? Well this is the Maple application for you!

This app, refurbished and modified to fit the budget and nutritional needs of a student, based on this older app: https://www.mapleprimes.com/maplesoftblog/34983-The-Diet-Problem, takes a list of more than 20 foods, and based on nutritional and budget constraints that you choose and can change, will give you the cheapest option for foods that fits your needs!

Maybe you’re not a broke student, but rather someone who wants to keep track of calorie intake or macronutrient intake on a daily basis, well then this app still works for you!

Find it here:
https://www.maplesoft.com/applications/view.aspx?SID=154368

First 22 23 24 25 26 27 28 Last Page 24 of 71