Hello!

I use Maple to calculate a variety of physiology questions. But i keeps using the standardized SI unites and not the ones i plug in. Is there a way to get maple to behave differently? Ive added a screenshot of an example. It comes out in m3/s when i just want it in ml/min. 

GFR = (18.2*Unit(('mg')/('ml')))*1.5*Unit(('ml')/('min'))/(0.201*Unit(('mg')/('ml')));
 = 
                                            / 3\
                                            |m |
                GFR = 0.000002263681592 Unit|--|
                                            \s /

With the update of Maple 2025, I'm finding that every time I open a saved Maple worksheet (from say my desktop or File Explorer), Maple creates a new window rather than opening the worksheet in a previously opened window (as previous versions of Maple have done). 

Is there a way to prevent this? For context, I'm running Windows 11. 

I've been debugging this for 20 hrs and finally able to make an example.

I noticed that solve() suddenly no longer works and times out.

First time calling solve() works. Second time it I see message

               Warning, solve may be ignoring assumptions on the input variables.

And it hangs.  Same exact code.   It has to do with calling odetest before and using Physics:-Setup('assumingusesAssume' = false):

i.e. this works
  
     odetest(...) assuming integer
     solve(....) #no hang
     odetest(....) assuming positive

     odetest(...)  assuming integer
     solve(....)  #no hang

But this does not work

     odetest(...) assuming integer
     solve(....) #no hang
     Physics:-Setup('assumingusesAssume' = false):
     odetest(....) assuming positive
     Physics:-Setup('assumingusesAssume' = true):
     odetest(...) assuming integer
     solve(...)   #HANGS     

Here is worksheet showing the problem. If I remove first call to odetest, solve do not hang.

Also removing Physics:-Setup('assumingusesAssume' = false):, solve also works OK. (ie. does not hang)

So it has to do with some internal caching which causes solve to stop working.

Can others reproduce this and can cause it and how to fix it so solve do not hang second time?

The input used below is not important. It is just what I found to cause this. One would expect solve() to work same way for same input all the time.

Also, same problem happens when using PDEtools:-Solve instead of solve. It hangs second time.

Download why_solve_stops_working_maple_2025_may_28_2025.mw

This worksheet below shows that by removing Physics:-Setup('assumingusesAssume' = false): now solve works OK second time. (I turn on/off Physics:-Setup('assumingusesAssume' since I found sometimes it can help with odetest to turn it off in some other cases. But now I am scared of touching this setting as it seems to have side effects internally)

Download why_solve_stops_working_maple_2025_may_28_2025_V2.mw

I'm looking for a flatten procedure for matrices (without first having to convert the matrix to a list, flatten it, and finally convert it back).
In this example, I am trying to generalize the matrix R to higher dimensions (here a 3 by 3 matrix, denoted as A, is used). I'm using a function, denoted as g, to construct a matrix. Obviously, the function applies to each cell and therefore, each cell contains a matrix in the resulting matrix. A flatten command would solve the problem. As a work-around I reconstruct the matrix In this example, but that is hard to generalize to more dimensions (or not?)

Download Flatten_a_matrix.mw

Hi everyone, I have an old worksheet created back with Version 5 and I recently open it using the latest version of Maple and I am aware of the many upgrades since then but I can't get my program to work in the new application. Can anyone help me out? I put an extract of the code which I hope will work for everyone suggestion. 

restart:with(tensor):
coord := [t, r, p, q]:
g_compts := array(symmetric,sparse, 1..4, 1..4): g_compts[1,1] := -1: g_compts[1,2]:= 0:
g_compts[1,3]:= 0: g_compts[1,4]:= 0: g_compts[2,2]:= H(t,r,p,q)^2:
g_compts[2,3]:= 0:
g_compts[2,4]:= 0:
g_compts[3,4]:= 0:
g_compts[3,3] := F(t,r,p,q)^2: g_compts[4,4] := F(t,r,p,q)^2: g := create( [-1,-1], eval(g_compts));

ginv := invert( g, 'detg' ):
D1g:=d1metric( g, coord ): D2g:=d2metric( D1g, coord ):
Cf1 := Christoffel1 ( D1g ):
Cf2 := raise(ginv,Cf1,3): RMN := Riemann( ginv, D2g, Cf1 ):
RICCI := Ricci( ginv, RMN ):
RS := Ricciscalar( ginv, RICCI ): WEYL := Weyl( g, RMN, RICCI, RS):
Estn := Einstein( g, RICCI, RS ): Eup := raise(ginv,Estn,1): Ein:= get_compts(Eup): simplify(Ein[1,1]);

displayGR('Weyl', WEYL);

Hello,

I'm using CodeGeneration:-C in Maple to translate the coefficients of a dynamical model into C++ code. However, I'm running into an issue when trying to assign the output in a way that matches the format of the coef vector used in the main C++ file (which is set up to simulate any 3D quadratic model).

For context, ans is a Maple vector containing all 30 coefficients.
Taking ans[12] as an example:

ans := [0, -sigma, xi[1, 2], xi[1, 3], 0, 0, 0, 0, 0, 0, 0, -sqrt(-4*xi[1, 3]^2*xi[1, 2]^2 + 4*xi[1, 2]*xi[1, 3]*xi[2, 5] + 1)*rho*sigma/(2*xi[1, 2]) + sigma*rho/(2*xi[1, 2]), -sqrt(-4*xi[1, 3]^2*xi[1, 2]^2 + 4*xi[1, 2]*xi[1, 3]*xi[2, 5] + 1)*beta/2 + sqrt(-4*xi[1, 3]^2*xi[1, 2]^2 + 4*xi[1, 2]*xi[1, 3]*xi[2, 5] + 1)/2 - beta/2 - 1/2, -sqrt(-4*xi[1, 3]^2*xi[1, 2]^2 + 4*xi[1, 2]*xi[1, 3]*xi[2, 5] + 1)*beta*xi[1, 3]/(2*xi[1, 2]) + sqrt(-4*xi[1, 3]^2*xi[1, 2]^2 + 4*xi[1, 2]*xi[1, 3]*xi[2, 5] + 1)*xi[1, 3]/(2*xi[1, 2]) + beta*xi[1, 3]/(2*xi[1, 2]) - xi[1, 3]/(2*xi[1, 2]), 0, xi[2, 5], -sqrt(-4*xi[1, 3]^2*xi[1, 2]^2 + 4*xi[1, 2]*xi[1, 3]*xi[2, 5] + 1)/(2*xi[1, 2]^2) + xi[1, 3]*xi[2, 5]/xi[1, 2] + 1/(2*xi[1, 2]^2), 0, 0, 0, 0, sqrt(-4*xi[1, 3]^2*xi[1, 2]^2 + 4*xi[1, 2]*xi[1, 3]*xi[2, 5] + 1)*rho*sigma/(2*xi[1, 3]) + sigma*rho/(2*xi[1, 3]), sqrt(-4*xi[1, 3]^2*xi[1, 2]^2 + 4*xi[1, 2]*xi[1, 3]*xi[2, 5] + 1)*beta*xi[1, 2]/(2*xi[1, 3]) - sqrt(-4*xi[1, 3]^2*xi[1, 2]^2 + 4*xi[1, 2]*xi[1, 3]*xi[2, 5] + 1)*xi[1, 2]/(2*xi[1, 3]) + beta*xi[1, 2]/(2*xi[1, 3]) - xi[1, 2]/(2*xi[1, 3]), sqrt(-4*xi[1, 3]^2*xi[1, 2]^2 + 4*xi[1, 2]*xi[1, 3]*xi[2, 5] + 1)*beta/2 - sqrt(-4*xi[1, 3]^2*xi[1, 2]^2 + 4*xi[1, 2]*xi[1, 3]*xi[2, 5] + 1)/2 - beta/2 - 1/2, 0, -xi[1, 2]*xi[2, 5]/xi[1, 3] - sqrt(-4*xi[1, 3]^2*xi[1, 2]^2 + 4*xi[1, 2]*xi[1, 3]*xi[2, 5] + 1)/(2*xi[1, 3]^2) - 1/(2*xi[1, 3]^2), -xi[2, 5], 0, 0, 0]

When I run the command:

CodeGeneration:-C(ans[12],resultname="coef21");

the output is:

coef21 = -0.1e1 / (double) xi[0][1] * sqrt((double) (-4 * xi[0][2] * xi[0][2] * xi[0][1] * xi[0][1] + 4 * xi[0][1] * xi[0][2] * xi[1][4] + 1)) * rho * sigma / 0.2e1 + 0.1e1 / (double) xi[0][1] * sigma * rho / 0.2e1;

This is syntactically fine, but what I actually need is an assignment to coef[21] instead of coef21, to be consistent with the structure in my C++ code.

To clarify, the resultname must reflect an offset: ans[12] should become coef[12 + 9], ans[1] becomes coef[1 + 9], and so on. I realize this isn’t ideal, but the current C++ code has been working reliably for years, and adapting it would require unnecessary refactoring.

Do you have any suggestions on how to direct CodeGeneration:-C to generate the assignment with coef[21] as the left-hand side?

Many thanks in advance!

Ed

P.S. Using CodeGeneration:-C(ans[i], resultname = sprintf("coef%d", i + 9)) displays the coefficients on the screen as needed, but they still require some additional editing.

In Optical-Illusion--Impossible-Prisms, mcarvalho provides a Maple Learn worksheet to illustrate an intriguing optical illusion.  Here I do that illustration in Maple, and in 3D! 

The graphics below shows 4 bars.  Or is it 3 bars?

Download the worksheet, stare at the graphics for short while to grasp the nature of the optical illusion, and then rotate the 3D graph with the mouse and see the illusion fall apart.

optical-illusion.mw

Hi everyone,

I've encountered something odd while working with Maple's pdetest function. When I manually evaluate my proposed solution using eval() followed by simplify(), I get the expected identity 0 = 0, which suggests the solution satisfies the PDE. However, when I test the same solution using pdetest, it doesn't return zero. This inconsistency has left me unsure whether my solution is actually valid or if I'm missing something.

Has anyone else experienced this kind of discrepancy? Could this be due to how pdetest handles derivatives or symbolic simplification internally?

Any insights or suggestions would be greatly appreciated!

Download pde-test.mw

Hi,

I try to creat an activity on Statistics, and I'm stuck on the bar chart, ( in the last part of my worksheet) with xi on the x-axis (Ox) and ni on the y-axis (Oy). I'm using the BarChart command, but it's not giving the expected result.

Ideas?

S4_Statistiques_Descriptives_AxeTravail_Complet.mw

restart;

with(Physics);
with(Vectors);

Given

Ket(i) = alpha*Ket(u) + beta*Ket(d);
Ket(o) = gamma*Ket(u) + delta*Ket(d);
and using

<o|u><u|o> =1/(2)
<o|d><d|o> =1/(2)

 <i|d><d|i> =1/(2);
 <i|u><i|o> =1/(2);

Prove that
                     "alpha^*alpha = 1/2"

and the same for the rest of the unknowns

If you could help me start using them because later I will have a lot to check.

Thank you in advance for your help.

Mario

Geometrical entertainment in the form of rolling without slipping, now inside a torus.
You can also print out the corresponding equations - these graphs are # in the text, but it is better to do this separately from the geometric animation, because textplot3d takes up a lot of resources.

Please consider it not as a Maple program, but simply as an idea for a corresponding algorithm.
for_TORUS_IN_TORUS_for.mw
 

Grupo6_Tc1.mw

Should maple have given solution to x as zero in the following?

solve(x^n=0,x)

What if n is zero? what if n is negative?  

Another program I tried this on gives

Maple 2025

Hello,

I am working with the following overdetermined system of nonlinear equations in Maple and attempting to solve it for the unknowns xi[3] and xi[8].

Maple returns the following solution:

However, when I substitute the solution back into the original equations, the left-hand side should equal the right-hand side. Yet, using simplify(subs(solution, equation)) does not reduce the expression sufficiently to verify the equality.

Am I missing something in the simplification process?

Many thanks,

Ed