MaplePrimes - Questions, Posts, help, musings, answers ... all things Maple and math

Ask a Question

Create a Post

MaplePrimes Announcement

Announcing Maple 2025

by: Samir Khan 2031 Product: Maple 2025

March 25 2025

10 2

I’m absolutely delighted to announce the launch of Maple 2025!

Although you see a new release every year, new features take anything from a few fast-paced weeks to develop, to months of careful cultivation.

Working on so many features in parallel, each with varying time scales, isn't easy! We have to fastidiously manage and track our work.

So it's easy to lose ourselves in the daily minutiae of software development. To help us maintain perspective, we constantly ask ourselves questions like:

What user problem are we solving and how often does this problem occur?
Can we validate our proposed solution with preliminary user feedback?
Is this a solution to a problem that doesn't exist and will never exist, or are we pre-empting a future need?
Are we offering value to our users?

Given the answers, we course-correct to make sure we stay on track for our central mission - to make you happy, and to keep you coming back year-after-year.

With Maple 2025, I think we've smashed that goal. We have many new features that'll appeal to many different types of users - from students, educators and mathematicians, to engineers, scientists and technical professionals

Let me walk you through some of my personal highlights.

It’ll be difficult for anyone to miss this - Maple 2025 has a new interface! It’s a ribbon-based UI that look clean and contemporary, and helps you find and discover tools more quickly than before.

You have large, meaningful icons.

Items are logically grouped.

The ribbons is contextual. If you click on a plot, you get new tabs for interacting with and drawing on the plot.

A new Education tab collects pedagogical resources that were scattered around the interface in prior releases.

This is the biggest visual overhaul to Maple in many years. We hope you like it!

We also appreciate that changes in look and feel can be divisive. Please rest assured that we will refine and finesse the interface with each successive release; your comments and suggestions are most welcome.

The new interface is available on Windows and Linux, and as a technology preview on Mac.

The right arrow key on my keyboard is wearing out…and it’s all because of Maple. I’m knee deep in Maple nearly every day entering equations, and I’m always using right-arrow to move the cursor. It gets kind of tedious!

This anecdote reflects some investigative work we did. We comprehensively examined our internal library of thousands of Maple worksheets and discovered that these three input patterns are extremely common.

Previously, you’d use the right-arrow key to move the cursor out of the exponential, division or subscript.

Now, in Maple 2025, when you

type ^, /, or enter a literal subscript with a double-underscore,
followed by a number or symbol
and then input another operator (such as +)

the operator is automatically inserted on the baseline (except when y = 1).

Of course, you can also make the cursor return to or stay in the exponent or denominator with a simple keystroke, when that is what is needed.

This is one of those little quality of life refinements that I’m very fond of - it’s a little visual and usability dopamine hit.

The sum command (and its typeset form) now indexes into vectors without you needing to spam unevaluation quotes all over your expression.

Maple 2024	Maple 2025

We’ve been integrating units deeper into the Maple system, release after release. Much of this is driven by our engineering users.

A few releases ago, we made int(numeric) compatible with units. With Maple 2025, you can now numerically differentiate expressions and procedures that have units.

I’m a grizzled thermodynamics hack, so here’s an example in which I calculate the specific heat capacity of water by differentiating enthalpy with respect to temperature (and then confirm the result with the built-in value):

This is in addition to many other improvements to the units experience.

Although this is a part of Maple that I don’t touch often (my colleague Karishma takes point on the education side), I REALLY wish I’d had this when I was struggling with math.

You can now automatically generate unlimited variants of the same problem for students to solve with the Try Another feature, which has been added to Maple’s Check My Work tools (another feature I really could have used!). This is available for many common math principles, including factorization, simplification, integration and more.

This is just one of the improvements in Maple 2025 for teaching and learning.

If you’ve ever found yourself going back and forth (and back and forth) between two large, almost identical-looking Maple expressions, trying to figure out how they are different, you’re going to love this one. ExpressionTools is a new package that lets you compare the differences between two expressions.

I really like the use of color to highlight differences. Less squinting at the screen!

You can now run Maple Flow worksheets from Maple (you don’t need Maple Flow installed to do this). You can send parameters into the Flow worksheet and extract your desired results.

This means you can use the entire flexibility of Maple to analysis and manipulate your Flow worksheet. You could, for example:

Attach a Flow worksheet to a Maple workbook and create an interactive application
Carry out parameter studies of a Flow worksheet by evaluating it over many parameter sets in Maple
Create an Excel interface for a Flow worksheet using the Maple add-in for Excel

Simplify is one of those functions that literally tens of thousands of people use each day. Every time we make an incremental improvement, the cumulative benefits across our entire user base are significant.

We’ve refined simplify in a number of critical ways. For example, simplify now recognizes when exponentials can be profitably converted to hyperbolic trig functions:

The analysis of many scientific phenomena result in Laplace transforms that do not have a symbolic inverse which can be expressed in terms of elementary functions. This includes applications in heat transfer, fluid mechanics, fractional diffusion processes, control systems and electrical transmission.

For example, this monster Laplace transform results from an analysis of voltage on a transmission line:

You can now numerically invert this transform courtesy of an enhancement to inttrans:-invlaplace - a fast quadrature method.

I’ve saved what I think has the most future potential for last.

I’m sure nearly all of you have experimented with the various AI tools. They’re an inevitable part of our present and future, whether we're comfortable with it or not.

This is something we've been mulling over for some time.

In Maple 2019, the DeepLearning package made its debut. This package provides tools for machine learning, supporting operations such as classification and regression using neural networks.
In Maple 2024, we introduced an AI-powered formula lookup feature.

In Maple 2025, we’re giving you an early-stage technology preview of AI-powered document generation.

You can automatically generate worksheet content by prompting an AI, and then gradually refine the content

If you’re an educator, you might want some content that describes applications of calculus. So you might ask the AI “How do I derive the formula for the area of a circle” by entering your prompt into this text box:

This is the worksheet content that may be returned:

If you’re structural engineer who wants to know how to calculate the hardness of concrete, you might ask the AI: “How do I calculate the compressive strength of slow hardening concrete as a function of time? Use the CEB-FIP Model Code 90. Include a worked example with Maple code”.

This worksheet content that could be generated (note the live Maple code):

We’re labelling AI-generated worksheet content as a technology preview. You might see

text that might be misleading (but sounds plausible)
code that doesn’t work (but looks plausible)
or different results each time you click “Generate Document”

For the moment, I would not rely on AI-generated worksheet content without realistic expectations, a healthy dose of scepticism and a modicum of detached analysis. But AI models are rapidly growing in robustness, and we want to position ourselves to best exploit their future potential. The next few years will be VERY exciting.

We can never cover everything in a short blog post like this. So if you want to know more, head on over to the What’s New pages for Maple 2025!

Read Full Post

Featured Post

dharr

7533

Maple in the Real World

Recently, @zenterix asked a question related to solving the quantum mechanics of the finite-wall-height particle-in-a-box problem. In the last two decades or so I've been teaching a quantum mechanics course every second year, in which I sketch the method of solution of this problem for the class, I but do not get into the mathematical details. A few times I've started to work on it in Maple, but abandoned it because of lack of time. So I decided to persist this time.

This post is more about some of the challenges and tradeoffs in making it work, hence the title. The title is also a nod to the fact that this problem appears in Engel's textbook [1] in a chapter entitled "Applying the particle in a box model to real-world topics". You don't need to know much about quantum mechanics to understand it. From the mathematical point of view you are solving three ordinary differential equations (in three regions) and stitching the solutions together so that the solution, a wavefunction, is continuous with continuous derivative and tends to zero at plus infinity and minus infinity.

The three regions and the wavefunctions for three eigenvalues (energies) are shown here in the figure, which is the final output of the worksheet. Next is the worksheet and I'll comment further on it below.

(It's a quirk of quantum mechanics that we plot two things with different units (wavefunctions and energy) on the same axis, and worse, we offset one by the other.)

Bound states for particle in finite height box of wall height
V(x) = piecewise(x < -(1/2)*a, V__0, -(1/2)*a <= x and x <= (1/2)*a, 0, (1/2)*a < x, V__0)
I'll call these regions left, box and right respectively.

Schroedinger equation. Here as elsewhere is implied.

-(1/2)*`&hbar;`^2*(diff(diff(psi(x), x), x))/m+V*psi(x)-E*psi(x)

(1)

Nondimensionalize length as units of box length, . Since is unitless probability, has dimensions so we define a dimensionless

tr := {x = a*X, psi(x) = Phi(X)/sqrt(a)}; NDSchroedinger := PDETools:-dchange(tr, Schroedinger, [X, Phi(X)], params = [`&hbar;`, m, a], simplify)

${x = a*X, psi(x) = Phi(X)/a^(1/2)}$

-((1/2)*`&hbar;`^2*(diff(diff(Phi(X), X), X))+a^2*m*Phi(X)*(E-V))/(a^(5/2)*m)

(2)

This will also change the normalization integrals, e.g., over the box region:

normint := Int(psi(x)^2, x = -(1/2)*a .. (1/2)*a); NDnormint := PDETools:-dchange(tr, normint, [X, Phi(X)], params = [`&hbar;`, m, a], simplify)

Int(psi(x)^2, x = -(1/2)*a .. (1/2)*a)

Int(Phi(X)^2, X = -1/2 .. 1/2)

(3)

Outside the box we have with . Define a dimensionless positive constant kappa:

>	$`κ__eqn` := kappa = asqrt(2m(V__0-E)/`&hbar;`^2); de_outside := simplify(sqrt(a)kappa^2*(eval(NDSchroedinger, {isolate(`κ__eqn`, m), V = V__0}))/(E-V__0)); outside := rhs(dsolve(de_outside))$

kappa = a*2^(1/2)*(m*(V__0-E)/`&hbar;`^2)^(1/2)

diff(diff(Phi(X), X), X)-kappa^2*Phi(X)

(4)

Inside the box we have and . Define a dimensionless positive constant .

>	$k__eqn := k = asqrt(2mE/`&hbar;`^2); de_box := simplify(-sqrt(a)k^2*(eval(NDSchroedinger, {isolate(k__eqn, m), V = 0}))/E); box := rhs(eval(dsolve(de_box), {c__1 = A, c__2 = B}))$

k = a*2^(1/2)*(m*E/`&hbar;`^2)^(1/2)

diff(diff(Phi(X), X), X)+k^2*Phi(X)

(5)

We have seven unknowns ${A, B, E, c__1(L), c__1(R), c__2(L), c__2(R)}$ , where for example means Maple's for the left region. We need seven equations: goes to 0 at and at (or wouldn't be square integrable), continuity at the two box boundaries, slopes continuous at the two box boundaries, and normalization. We deal with the ones at first.

At the wavefunction will be unbounded unless one of the constants goes to zero. We'll rename the other one or . The code here is just to handle the fact that and can be the the opposite way around, depending on the session.

$`assuming`(['limit(outside, X = -infinity)' = limit(outside, X = -infinity)], [kappa > 0]); left0 := eval(outside, `~`[`=`](`minus`(indets(rhs(%), name), {infinity}), 0)); left1 := eval(left0, `~`[`=`](indets(left0, suffixed(c)), A__L)); `assuming`(['limit(outside, X = infinity)' = limit(outside, X = infinity)], [kappa > 0]); right0 := eval(outside, `~`[`=`](`minus`(indets(rhs(%), name), {infinity}), 0)); right1 := eval(right0, `~`[`=`](indets(right0, suffixed(c)), A__R))$

(6)

Now we have five unknowns ${A, A__L, A__R, B, E}$ . The strategy will be to eliminate and then find the eigenvalues . Then we will have expressions for all three regions containing the unknown , which we will find by the normalization condition (The normalization condition fixes the scale of the wavefunction so that the probability of finding the particle somewhere is one.)

Continuity of the wavefunction and its derivative at the left boundary are below
We eliminate and using this boundary

>	$bcleft := {eval(left1-box, X = -1/2), eval(diff(left1, X)-(diff(box, X)), X = -1/2)}; sol := solve(bcleft, {A, A__L}); left2 := eval(left1, sol); box2 := eval(box, sol)$

${A__L*exp(-(1/2)*kappa)+A*sin((1/2)*k)-B*cos((1/2)*k), A__L*kappa*exp(-(1/2)*kappa)-A*k*cos((1/2)*k)-B*k*sin((1/2)*k)}$

${A = -B*(sin((1/2)*k)*k-cos((1/2)*k)*kappa)/(sin((1/2)*k)*kappa+cos((1/2)*k)*k), A__L = B*k*(sin((1/2)*k)^2+cos((1/2)*k)^2)/(exp(-(1/2)*kappa)*(sin((1/2)*k)*kappa+cos((1/2)*k)*k))}$

B*k*(sin((1/2)*k)^2+cos((1/2)*k)^2)*exp(kappa*X)/(exp(-(1/2)*kappa)*(sin((1/2)*k)*kappa+cos((1/2)*k)*k))

-B*(sin((1/2)*k)*k-cos((1/2)*k)*kappa)*sin(k*X)/(sin((1/2)*k)*kappa+cos((1/2)*k)*k)+B*cos(k*X)

(7)

Eliminate at the right box boundary

>	$bcright := {eval(box2-right1, X = 1/2), eval(diff(box2, X)-(diff(right1, X)), X = 1/2)}; elim := eliminate(bcright, A__R); right2 := eval(right1, elim[1]); energy_eqn := elim[2][]/B$

${-B*(sin((1/2)*k)*k-cos((1/2)*k)*kappa)*sin((1/2)*k)/(sin((1/2)*k)*kappa+cos((1/2)*k)*k)+B*cos((1/2)*k)-A__R*exp(-(1/2)*kappa), -B*(sin((1/2)*k)*k-cos((1/2)*k)*kappa)*k*cos((1/2)*k)/(sin((1/2)*k)*kappa+cos((1/2)*k)*k)-B*k*sin((1/2)*k)+A__R*kappa*exp(-(1/2)*kappa)}$

$[{A__R = B*(2*sin((1/2)*k)*cos((1/2)*k)*kappa+2*cos((1/2)*k)^2*k-k)/(exp(-(1/2)*kappa)*(sin((1/2)*k)*kappa+cos((1/2)*k)*k))}, {-2*(sin((1/2)*k)*cos((1/2)*k)*k^2-sin((1/2)*k)*cos((1/2)*k)*kappa^2-2*cos((1/2)*k)^2*k*kappa+k*kappa)*B}]$

B*(2*sin((1/2)*k)*cos((1/2)*k)*kappa+2*cos((1/2)*k)^2*k-k)*exp(-kappa*X)/(exp(-(1/2)*kappa)*(sin((1/2)*k)*kappa+cos((1/2)*k)*k))

(8)

Now we will get the quantized energies by finding which values will make energy_eqn zero. We recall the relationships of and to energy:

k = a*2^(1/2)*(m*E/`&hbar;`^2)^(1/2)

kappa = a*2^(1/2)*(m*(V__0-E)/`&hbar;`^2)^(1/2)

(9)

The energy scale is set by , so can get a non-dimensionalized energy and a non-dimensional parameter b = a*sqrt(2*m*V__0/`&hbar;`^2) .

>	$b__eqn := b = asqrt(2m*V__0/`&hbar;`^2); e__eqn := e = E/V__0; eqns := `assuming`([{simplify(eval(eval(k__eqn, isolate(e__eqn, E)), isolate(b__eqn, V__0))), simplify(eval(eval(`κ__eqn`, isolate(e__eqn, E)), isolate(b__eqn, V__0)))}], [a > 0])$

b = a*2^(1/2)*(m*V__0/`&hbar;`^2)^(1/2)

${k = (e*b^2)^(1/2), kappa = (-b^2*(e-1))^(1/2)}$

(10)

So now for any values of the box length and height, one finds the parameter describing the problem and solves for the possible values.

(11)

Maple cannot find an analytical solution, so we will find the eigenvalues numerically. The zero solution is unphysical.

0, RootOf(-2*(-(_Z^2-b^2)/b^2)^(1/2)*(_Z^2/b^2)^(1/2)*b^2+2*tan(_Z)*_Z^2-tan(_Z)*b^2)^2/b^2

(12)

For any , read off the possible energies off the vertical line for that , e.g. there are 3 bound states for . For other values, choose and on the next line appropriately.

(13)

In terms of the parameters and and normalization constant , the non-dimensionalized wavefunctions of the 3 regions are as below. The scale factor gives a simpler form and prevents 0/0 problems later in the calculation.

scale := `assuming`([denom(simplify(eval(left2, eqns)))], [positive]); left3 := `assuming`([simplify(eval(scale*left2, eqns))], [positive]); box3 := `assuming`([simplify(eval(scale*box2, eqns))], [positive]); right3 := `assuming`([simplify(eval(scale*right2, eqns))], [positive])

-(sin((1/2)*b*e^(1/2))*(e^(1/2)*sin(b*e^(1/2)*X)-(-e+1)^(1/2)*cos(b*e^(1/2)*X))-cos((1/2)*b*e^(1/2))*(cos(b*e^(1/2)*X)*e^(1/2)+sin(b*e^(1/2)*X)*(-e+1)^(1/2)))*B

(14)

It remains to find the normalization constant . The three parts of the normalization integral are:

P__L := `assuming`([int(left3^2, X = -infinity .. -1/2)], [positive]); P__box := `assuming`([int(box3^2, X = -1/2 .. 1/2)], [positive]); P__R := `assuming`([int(right3^2, X = 1/2 .. infinity)], [positive])

(1/2)*B^2*e/(b*(-e+1)^(1/2))

-(1/4)*B^2*(2*e^(1/2)*(-e+1)^(1/2)*cos(2*b*e^(1/2))-2*e^(1/2)*(-e+1)^(1/2)-2*b*e^(1/2)-2*e*sin(2*b*e^(1/2))+sin(2*b*e^(1/2)))/(b*e^(1/2))

(1/2)*B^2*(e^(1/2)*cos(b*e^(1/2))+(-e+1)^(1/2)*sin(b*e^(1/2)))^2/(b*(-e+1)^(1/2))

(15)

Solve for . There are two (messy) solutions for of opposite sign; it is conventional to choose the sign such that the ground state has positive values.

Assemble it into a single piecewise function.

`Φ__all` := eval(piecewise(X < -1/2, left3, `and`(X >= -1/2, X <= 1/2), box3, X > 1/2, right3), B = Bval)

Plot. Plots offset vertically by the energy as usual

$Xmax := 1.5; psiscale := .15; colors := [red, blue, magenta]; wavefns := plot([seq(eval(psiscale*`Φ__all`, {b = bval, e = evals[i]})+evals[i], i = 1 .. nsols)], X = -Xmax .. Xmax, color = colors); walls := plot([-1/2, y, y = 0 .. 1], color = black), plot([1/2, y, y = 0 .. 1], color = black), plot(1, X = -Xmax .. -1/2, color = black), plot(0, X = -1/2 .. 1/2, color = black), plot(1, X = 1/2 .. Xmax, color = black); evalplot := plot(evals, X = -Xmax .. Xmax, linestyle = dash, color = colors); plots:-display(wavefns, walls, evalplot, axes = boxed, labels = [X, psiscale*Phi+E/V__0])$

Download finite_box_non-dim2.mw

Comments
1. The first general comment is about the issue of how much Maple can do. In principle one should be able to give dsolve the three ODEs and the boundary conditions and it should output the result. We are still far away from that. Even for one region, the boundary conditions at infinity are not handled by dsolve. The other extreme is to solve the ODEs for their general solutions, and follow the algebraic manipulations for implementing the boundary conditions as one might do it on paper. Engel for example has a comment "At this point we notice that by dividing the equations in each pair, the coefficients can be eliminated to give [...]". Maple will not easily do that trick or the manipulations that led to the special form on which the trick is applied. Levine's textbook [2] gives a different non-intuitive set of steps.

But Maple can solve complicated equations, so I wanted a more general strategy that avoids as much as possible the requirement to manipulate into special forms. On the other hand, it is tempting (as @zenterix tried) to just give the three general solutions with 6 arbitrary constants and the boundary conditions to Maple's solve, and solve for the six constants. One finds that all six are zero. This us a consequence of the fact that the ODEs are linear, and misses the crucial point that it is an eigenvalue problem. So there must be some sort of step-by-step guidance for Maple and there is a general but non-obvious strategy to solving such problems.

2. The second general comment is that there is a trade-off between presenting the solution steps without any arcane Maple code, and getting to the solution efficiently and programmatically, without too many manual manipulations. One of my suggestions to @zenterix involved manually dividing both sides of an equations by a fairly complicated expression, to which @acer expressed a preference for programmatic solutions. At the time, I mainly did that to keep close the to existing solution, and was thinking that I usually set things up so that is not necessary. But I found here that I do it a lot, and it is a natural consequence of the interactive way I use Maple. Here's two examples:

In the second line of label (4), I originally got a more complicated form of de_outside, then manually figured out the factor to put inside simplify to get the form you see. I do this frequently with Maple, especially when I use dchange.

In the last line of label (8), I manually divided by B to remove it. Had B been in the denominator, I could have removed it programmatically with numer (an operation I use frequently, though it somewhat recklessly ignores denominator zeroes).

Programmatically doing things can be relatively unreadable and disrupt the readability for the non-Maple reader. For example in label (6) there is "extraneous" code to find which coefficient to set to zero so that the solution goes to zero at +/- infinity. This was forced on me since after generating the nice figure I re-ran the worksheet only to have multiple errors. I originally used eval(outside, {c__1 = B__L, c__2 = A__L}); to change Maple's dsolve constants to read the way I wanted. But I realized that dsolve does not reproducibly assign c__1 and c__2 to the same term each time, raising the general issue of:

3. Session to session reproducibility. If I am only going to use a worksheet myself, I don't usually worry too much about this, since I can usually debug this fairly easily. On the other hand if the worksheet is for others, it needs to be foolproof. I have taken to always sorting the output of solve, e.g., the assignment to bval in the execution group after label (15). The code added for the dsolve constants works, but is non-trivial Maple (suffixed type testing). (Solving this issue for Eigenvectors is yet more difficult.)

4. Some efforts to make the worksheet more readable were hard to do.

- For some reason, Engel chose to call the two constants in the left region B and B'. Entering B*exp(-k*x) + B'*exp(k*x) in 2D leads to B(x)*exp(-k*x) + diff(B(x), x)*exp(k*x). No doubt this can be fixed, but I didn't pursue this.

- I would normally use upper case Psi for the non-dimensionalized psi, but Psi is the name of a special function in Maple. But wait, now we can use "local Phi;" to solve this problem. However diff(Psi(x),x,x) displays as Psi(2,x), so I had to settle for Phi. (SCR submitted.)

- I build up the left wavefunctions incrementally as expressions assigned to left1, left2, etc, which is rather ugly. Why not use arrow procedures so we can use psi(x), D(psi)(x) etc. Aside from some awkwardness in updating such procedures by redefining them as needed, I ran into the following problem:

limit(A*exp(-k*x) + B*exp(k*x), x = infinity) assuming k > 0; gives as expected
signum(B)*infinity;

but

psi := x -> A*exp(-k*x) + B*exp(k*x);
limit(psi(x), x = infinity) assuming k > 0;
returns unevaluated. What happened to full evaluation?

- I'm used to entering hbar as hbar in 1D; it displays as h with the bar through. In 2-D entering hbar^2 is displayed nicely, but internally it is `&hbar;`. We can have the following puzzle:

- I originally wanted a vertical axis label Psi, E/V__0, but labels = [X, Psi, E/V__0] obviously won't work. It took some time to figure out the answer is to make "Psi, E/V__0" an atomic variable. I finally settled on the more honest, if cryptic, label shown.

5. solve gives an "invalid" solution. Originally I worked with solutions left2 etc (see label (6)) after simplify(eval(left2, eqns)). Every second wavefunction was about 10^9 times higher than the others, which was difficult to debug. It turns out the denominator of those wavefunctions was exactly zero but numerically 10^(-10), meaning they plotted as large-scaled versions of the right shape, without any division-by-zero error. The fix is to remove the denominators by scaling (see label (14)).

This is just a consequence of Maple giving generic solutions, and the only way around it is to be aware of it.

Summary

To solve such problems with Maple requires one to play around in an interactive way. After hacking to a solution, it can take some effort to make it presentable and usable to others. But the final result is pleasing, and is certainly much easier than working through the problem on paper. The ability to manipulate complicated expressions means circumventing tricks that might be needed in manual solutions.

References
[1] T. Engel, Quantum Chemistry and spectroscopy. Pearson 2019, 4th ed. Sec. 5.1, Prob. 5.3.
[2] I. N. Levine, Quantum Chemistry. Pearson 2009, 6th ed. Sec. 2.4.

March 05

8 2

Read Full Post

Featured Post

ecterrab

14295

Computing Einstein's equations using variational principles

Edgardo S. Cheb-Terrab

Freddy Baudine

One of the biggest challenges for a computer algebra system is to compute Einstein's equations from first principles, by equating to zero the functional derivative of the Action for gravity, without using human-shortcuts or tricks. Developments during 2024, appearing as new in Maple 2025, broke through that barrier and now the LagrangeEquations Physics command, introduced in 2023, can perform that elusive computation of Einstein's equations, not using tabulated cases, properly handling several (traditional or not) alternative ways of presenting the Lagrangian (the integrand in the Action), taking advantage of the functional differentiation capabilities of the Physics package .

The computation can be performed in one call to Physics:-LagrangeEquations, or in steps interactively using the Physics:-Fundiff and Physics:-Simplify commands that include newly implemented capabilities for simplifying tensorial expressions in curved spacetimes. This is an exciting breakthrough/milestone in Computer Algebra, also in an area out of reach of neural network AIs.

Einstein's equations are a system of second order nonlinear coupled partial differential equations for the 10 components of the spacetime metric

Physics:-g_[mu, nu] = Matrix(%id = 36893488152225885228)

(1)

In the Lagrangian formulation, the coordinates of the problem are the 10 components of the metric,

(2)

and the parameters of the variational problem are the spacetime coordinates .

The traditional Lagrangian

The simplest case is that of Einstein's equation in vacuum, for which the Lagrangian density is expressed in terms of the trace of the Ricci tensor and the determinant of the metric by

(3)

What was almost a dream in previous years, Einstein's equations can now be computed in one simple instruction as the Lagrange equations for this Lagrangian, in the traditional compact form, taking the components of the metric tensor as the coordinates (for an interactive, step by step computation, see further below)

-(1/2)*Physics:-g_[mu, nu]*Physics:-Ricci[alpha, `~alpha`]+Physics:-Ricci[mu, nu] = 0

(4)

The tensorial equation computed is also the definition of the Einstein tensor

Physics:-Einstein[mu, nu] = -(1/2)*Physics:-g_[mu, nu]*Physics:-Ricci[alpha, `~alpha`]+Physics:-Ricci[mu, nu]

(5)

A Lagrangian depending only on first derivatives of the metric

The Lagrangian used to compute Einstein's equations (4) contains first and second derivatives of the metric; the latter make the computation significantly more complicated. The second order derivatives, however, can be removed from the formulation. To see that, rewrite L in terms of Christoffel symbols

(6)

Recalling the definition

Physics:-Christoffel[alpha, mu, nu] = (1/2)*Physics:-d_[nu](Physics:-g_[alpha, mu], [X])+(1/2)*Physics:-d_[mu](Physics:-g_[alpha, nu], [X])-(1/2)*Physics:-d_[alpha](Physics:-g_[mu, nu], [X])

(7)

in the two terms containing derivatives of Christoffel symbols contain second order derivatives of .

Now, it is always possible to add a total spacetime derivative to without changing Einstein's equations (assuming the variation of the metric in the corresponding boundary integrals vanishes), and in that way, in this particular case of , obtain a Lagrangian involving only 1st order derivatives. The total derivative, expressed using the inert command to see it before the differentiation operation is performed, is

(8)

Adding this term to , performing the differentiation operation and simplifying we get

(9)

(10)

(11)

which is a Lagrangian depending only on 1st order derivatives of the metric through Christoffel symbols. As expected, the equations of motion resulting from this Lagrangian are the same Einstein equations computed in (4); this computation can also now be performed in a single call

-(1/2)*Physics:-Ricci[iota, `~iota`]*Physics:-g_[mu, nu]+Physics:-Ricci[mu, nu] = 0

(12)

Simplification capabilities developed to cover these computations

To illustrate the new Maple 2025 tensorial simplification capabilities note that is no just ≡ (6) after discarding its two terms involving derivatives of Christoffel symbols. To verify this, split into the terms containing or not derivatives of Christoffel

(13)

Comparing, the total derivative TD≡ (8) is not just , but

(14)

Things like these, , can now be verified directly with the new tensorial simplification capabilities: take the left-hand side minus the right-hand side, evaluate the inert derivative and simplify to see the equality is true

(15)

(16)

(17)

That said, it is also true that results in the Lagrangian , and since the equations of movement don't depend on the sign of the Lagrangian, for this Lagrangian adding the term happens to be equivalent to just discarding the terms of involving derivatives of Christoffel symbols.

Derivation step by step using functional differentiation (variational principle)

Also new in Maple 2025, due to the extension of Fundiff to compute in curved spacetimes, it is now possible to compute Einstein's equations from first principles by constructing the action,

Int(Int(Int(Int((-%g_[determinant])^(1/2)*Physics:-Ricci[alpha, `~alpha`], x = -infinity .. infinity), y = -infinity .. infinity), z = -infinity .. infinity), t = -infinity .. infinity)

(18)

and equating to zero the functional derivative with respect to the metric. To avoid displaying the resulting large expression, end the input line with ":"

Simplifying this result, we get an expression in terms of Christoffel symbols and its derivatives

(19)

In this result, we see derivatives of Christoffel symbols, expressed using the D_ command for covariant differentiation. Although, such objects have not the geometrical meaning of a covariant derivative, computationally, they here represent what would be a covariant derivative if the Christoffel symbols were a tensor. For example,

(20)

With this computational meaning for the derivatives of Christoffel symbols appearing in (19), rewrite EEC≡(19) in terms of the Ricci and Riemann tensors. For that, consider the definition