I get this ->

But would like this ->

First impressions, I have mixed feelings - one being it's cool and new, the other feeling that it's a bit clunky.

In my opinion Maple is starting to look like the interface is being modelled after Microsoft Office, or like the ribbon toolbars of AutoCad or Inventor.  Maple's "uniqueness" is disappearing.  I rather liked the old interface. 

The toolbar icons are larger, taking up more space.

The toolbar layout is indeed simpler, but also less efficient maybe.  I mean there were more useful available icons at once before, more functional is the word I guess.  Now it might be a couple of clicks away to pull up your favorite icon(s).  The icons all look very nice, that's a plus but they could be smaller.  

Perhaps we could make a customized menu toolbar?  That is, allow users to put all the most useful icons we use or would like the most to be displayed?  This would help some of the strange organization of some of the icons and allow us to make our maple "sandbox" feel more at home. 

Where have all the tools options display / interface / Precision tabs all gone?  That is typsetting (extended or Maple standard) options
plot or font anti-aliasing (Enabled Disabled) options
plot dislpay (inline window) options
Precision (limit expression length to etc...)

What is the installation time for Maple 2025?

I looked up the installation times for Matlab and Mathematica.  The AI assistant in google says Matlab takes several minutes to an hour, for Mathematica 20 minutes to an hour, for Maple it said around 15 minutes -  Is that about right? 

It is very strange, but I cannot find in v. 2025 shortcut or a button for stoping current evaluation.

I had no problem with this in previous version, but now the absence of immediate stoping make troubles for me,

(1) The gray line above the working area is redundant.

(2) Line Style, Color, and the "Delete" key function to delete object are not working properly.

(3) IdentifySequence([1,3,5,7,9]) without the second argument does not work.

(4) IdentifySequence should first identify simple patterns (Arithmetic Progression, Geometric Progression, Arithmetic-Geometric Progression, Harmonic Progression) before attempting to find a more complex formula for the nth term of the sequence.

(5) It would be beneficial if IdentifySequence recognized sequences involving rational, irrational and symbolic numbers.

Hello,

I need to sort a list of monomials in a custom order based on two criteria:

1. Increasing total degree (e.g., x<x^2)

2. Lexicographic order within the same degree, using a specified variable order such as x<y<z.

For example, given the list:

L := [z^2, y*z, x*z, z, y^2, x*y, y, x^2, x, 1] 

and the variable order (which can be changed by the user):

vars := [x, y, z]; 

I would like the output to be:

[1, x, y, z, x^2, x*x, x*y, x*z, y^2, y*z, z^2]

Is there a built-in function or a recommended way to achieve this in Maple?

Thank you!

Wondering what the experts here think of this. Should not simplify have worked on this automatically? By trial and error, found that combine command is what simplified it the best.

But I think simplify should also have done the same.  

Interested to hear what others think, and why simplify (even using trig option) did not do it.   

The issue is that this is done in code, without lookin at the screen and deciding what to do based on what the expression "looks like".

Download simplify_vs_combine_june_4_2025.mw

This could be unrelated to V 26 of support tools and it could be a bug that existed in Maple before.

But no time for me to check now. Thought to ask about it before I forget.

When adding Physics:-Setup('assumingusesAssume'=true):  Maple generated internal error that can not be cought.

This is using latest V 26 of support tools

Download type_complex_recursion_june_4_2025_V26_support.mw

I was debugging another Maple problem and found this.

According to help, it says

Computations performed using assuming do not affect computations performed before or after calling assuming.

But this example below shows this is not the case at all.

I used hasassumptions(y(x)); before calling a command that uses assuming, and it gave false as expected since there are no assumption put on y(x).

After the command is complete, now I find that  hasassumptions(y(x)); returns true  which is wrong. 

This only happens when adding Physics:-Setup('assumingusesAssume'=true); and also when the command that uses assuming timesout.

But from help, this should not cause this. Here is the help on this

assumingusesAssume
  true or false.

The default for this option is true, so that, when Physics is loaded, the Maple assuming command uses Physics:-Assume to place temporary assumptions. This makes the assuming command fully compatible with the Physics, DifferentialGeometry, DifferentialAlgebra and VectorCalculus packages. It is recommended to not change this setting. If assumingusesAssume is set to false, temporary assumptions placed by assuming are placed using the assume command, which redefines the variables receiving assumptions, so that, depending on the computation, the commands of these packages mentioned will fail in recognizing them within expressions (for example: when placing assumptions on the coordinates and computing with the spacetime metric).

Could someone please explain in very simple terms (as I find all this very confusing), why that after calling a command which uses assuming, I find my variables have assumption still attached to them? 

Because of this, commands that uses these variables after this will and could fail depending on what command is used.

This explains many of the problems I am seeing when using assuming command.  

My question is simple: Should any variable which did not have assumptions on it, still not have assumptions on it after using assuming regadless if the command that uses assuming timedout or not?

Notice that I am not even using the Physics package explicitly anywhere in the following. I am just called odetest with timeout.

Here is worksheet to illustrate this.

Download why_variable_have_assumption_june_3_2025.mw

My quess is this: Because the command that uses assuming timedout, Maple failed to remove/clear any temporary assumptions it added to the variables involved.   But this only happens when using Physics:-Setup('assumingusesAssume'=true):

If the command did not timeout, this does not happen. At least on some examples I tried this on.

After updating to V 22 of supportTools, I found a new error.

This works sheet using V 22 gives this

Download bug_in_odetest_with_lambertW_june_2_2025.mw

But same code works OK in V 21

Download no_bug_in_odetest_with_lambertW_june_2_2025.mw

This is not a big deal, but I was wondering why it changed. Before, after doing SupportTools:-Version(latest); to get latest version, the message used to say to just do restart; to use the new version of SupportTools (i,e. no need to close all of Maple). (I remember this, but I have no screen shot now to show this old message). I always used to just do restart; and it always worked.

Now, with version 22, the message changed, it now says to close and restart all of Maple

Why this change happened?  

Maple 2025 on Linux

I have a symbolic block matrix equation that I am trying to solve. Maple doesn't respect non-commutativity when solving.

I've tried to use 'Matrix' assumptions. I've also tried using the Physics package's Setup(noncommutativeprefix).

Both of these do not respect the order of multiplications (even using the dot operator for multiplication).

I've posted a minimal example below.

Download noncommutative_example.mw

Does anyone know of a way to make this come out in a sensible fashion?
Thanks for the help!

Hello,

I would like to determine the level of nested lists within a list.

For example, given:

L := [[1, 2, 3], [], [[1, 2], [3, 4], [5, 6]], [[[1, 2], [3, 4]], [[5, 6], [7, 8]]]];

I would like to compute:

nL := [1, 1, 2, 3];

That is, for each element in L, return the depth of nesting.

Additionally, I would like to write a procedure that takes L and returns a flattened version at the first non-empty list level:

L1 := [[1, 2, 3], [], [1, 2], [3, 4], [5, 6], [1, 2], [3, 4], [5, 6], [7, 8]];

Thank you in advance for your help!

Ed

For some reason, I get dozens of ode's that fail to odetest when using method='laplace' with dsolve.

Yet, all the solutions are correct. These are from textbooks.

I tried giving odetest assumptions but nothing worked so far. So I am thinking of just ignoring result of odetest when laplace method is used and to assume it is correct each time. Otherwise, I will get false negative all the time on these.

Thought to ask if someone knows why this happens and if there is some universal trick to use when calling odetest on such solutions.

Here is worksheet with few examples where odetest do not verify the solutions (even though they are "correct", when solving these ode's by hand). 

May be if odetest was told that the solution was generated using method='laplace' it will help it, but there is no such option (as in the case with 'series' option). 

Btw, if method='laplace' is not used on these examples, then odetest have no problem verifying the solutions and gives zero on all of them.

Download how_to_odetest_laplace_solution_may_29_2025.mw