Hello all,

This is a post for a software change.

I think it would be great if Maple had some constructions for :

i++

++i

i--

--i and idem for multiply and divide.

I guess it is too late for Maple 2026, but maybe this could be added for 2027.

i++ does work however.

Have a great day.

Jean-Michel

PS:You must have a reputation score of at least 100 to add a new tag. (???)

Sorry : I just see that this  is already implemented in Maple.

Thank you

This way back machine shows how Maple debugger looked like in the year 2005 (that is 20 years ago) in Maple 10.

And it is pretty much the same debugger today. Here is a screen shot side by side of recent version

20 YEARS and nothing changed.

The debugger in Maple is one, if not the main, selling point for Maple compared to its competitor for many.

Even the article above says this

     "But the big plus about the Maple language is that it has a debugger! "

     "Also, the existence of a reasonable debugger in Maple is a big plus. From
      personal experience, I can tell you that debugging Mathematica Notebooks
     can be both time consuming and frustrating."

Can the debugger be improved, so it is easier to use? 

All what is needed is to change the UI so  one can see more code as they are stepping in, like with Matlab debugger for example.

That is all. Currently it is a pain using the debugger, since one only sees one or 2-3  lines at time as they step in the code instead of seeing complete code with full screen which makes it much easier to see things.

Instead of Maplesoft wasting time on AI and cosmetics, do something practical for developers and improve the debugger.

It should not take a software company 40 years just to improve a UI for a debugger. What is the blocking issue here? 

Just hire one or two programmers and they can do this in 6 months.

It would be useful to have Time-Frequency signal processing tools in Maple, for non-stationary spectral analysis. One example is the Wigner-Ville Transform, along with a range of others (e.g. STFT)

The inscribed square problem, also known as the Toeplitz conjecture, is an unsolved quastion in geometry: Does every plane simple closed curve (Jordan curve) contain all four vertices of some square? This is true if the curve is convex or piecewise smooth and in other special cases. The problem was proposed by Otto Toeplitz in 1911. For detailes see  https://en.wikipedia.org/wiki/Inscribed_square_problem

The Inscribed_Square procedure finds numerically one or more solutions for a curve defined by parametric equations of its boundary or by the equation F(x,y)=0. The required parameter of procedure  L  is the list of equations of the boundary links or the equation  F(x,y)=0 . Optional parameters:  N  and  R . By default  N='onesolution' (the procedure finds one solution), if  N  is any symbol (for example  N='s'), then more solutions.  R  is the range for the length of the side of the square (by defalt  R=0.1..100 ).

The second procedure  Pic  visualizes the results obtained.

The codes of the procedures:

restart;
Inscribed_Square:=proc(L::{list(list),`=`},N::symbol:='onesolution',R::range:=0.1..100)
local D, n, c, L1, L2, L3, f, L0, i, j, k, m, A, B, C, P, M, eq1, eq2, eq3, eq4, eq5, eq6, eq7, eq8, eq9, sol, Sol;
uses LinearAlgebra;
if L::list then
L0:=map(p->`if`(type(p,listlist),[[p[1,1]+t*(p[2]-p[1])[1],p[1,2]+t*(p[2]-p[1])[2]],t=0..1],p), L);
c:=0;
n:=nops(L);
for i from 1 to n do
for j from i to n do
for k from j to n do
for m from k to n do
A:=convert(subs(t=t1,L0[i,1]),Vector): 
B:=convert(subs(t=t2,L0[j,1]),Vector):
C:=convert(subs(t=t3,L0[k,1]),Vector): 
D:=convert(subs(t=t4,L0[m,1]),Vector):
M:=<0,-1;1,0>;
eq1:=eval(C[1])=eval((B+M.(B-A))[1]);
eq2:=eval(C[2])=eval((B+M.(B-A))[2]);
eq3:=eval(D[1])=eval((C+M.(C-B))[1]);
eq4:=eval(D[2])=eval((C+M.(C-B))[2]);
eq5:=eval(DotProduct(B-A,B-A, conjugate=false))=d^2;
sol:=fsolve([eq1,eq2,eq3,eq4,eq5],{t1=op([2,2,1],L0[i])..op([2,2,2],L0[i]),t2=op([2,2,1],L0[j])..op([2,2,2],L0[j]),t3=op([2,2,1],L0[k])..op([2,2,2],L0[k]),t4=op([2,2,1],L0[m])..op([2,2,2],L0[m]),d=R});
if type(sol,set(`=`)) then if N='onesolution' then return convert~(eval([A,B,C,D],sol),list) else c:=c+1; Sol[c]:=convert~(eval([A,B,C,D],sol),list) fi;
 fi; 
od: od: od: od:
Sol:=fnormal(convert(Sol,list),7);
print(Sol);
ListTools:-Categorize((X,Y)->`and`(seq(is(convert(X,set)[i]=convert(Y,set)[i]),i=1..4)) , Sol);
return map(t->t[1],[%]);
else
A,B,C,D:=<x1,y1>,<x2,y2>,<x3,y3>,<x4,y4>:
M:=<0,-1;1,0>:
eq1:=eval(C[1])=eval((B+M.(B-A))[1]):
eq2:=eval(C[2])=eval((B+M.(B-A))[2]):
eq3:=eval(D[1])=eval((C+M.(C-B))[1]):
eq4:=eval(D[2])=eval((C+M.(C-B))[2]):
eq5:=eval(LinearAlgebra:-DotProduct((B-A,B-A), conjugate=false))=d^2:
eq6:=eval(L,[x=x1,y=y1]):
eq7:=eval(L,[x=x2,y=y2]):
eq8:=eval(L,[x=x3,y=y3]):
eq9:=eval(L,[x=x4,y=y4]):
sol:=fsolve({eq1,eq2,eq3,eq4,eq5,eq6,eq7,eq8,eq9},{seq([x||i=-2..2,y||i=-2..2][],i=1..4),d=R});
eval([[x1,y1],[x2,y2],[x3,y3],[x4,y4]], sol):
fi;
end proc:

Pic:=proc(L,Sol,R::range:=-20..20)
local P1, P2, P3, T;
uses plots, plottools;
P1:=`if`(L::list,seq(`if`(type(s,listlist),line(s[],color=blue, thickness=2),plot([s[1][],s[2]],color=blue, thickness=2)),s=L), implicitplot(L, x=R,y=R, color=blue, thickness=2, gridrefine=3));
P2:=polygon(Sol,color=yellow,thickness=0);
P3:=curve([Sol[],Sol[1]],color=red,thickness=3):
T:=textplot([[Sol[1][],"A"],[Sol[2][],"B"],[Sol[3][],"C"],[Sol[4][],"D"]], font=[times,18], align=[left,above]);
display(P1,P2,P3,T, scaling=constrained, size=[800,500], axes=none);
end proc:

Examples of use:

The curve consists of a semicircle, a segment and a semi-ellipse (find 1 solution):

L:=[[[cos(t),sin(t)],t=0..Pi],[[t,0],t=-1..0],[[0.5+0.5*cos(t),0.8*sin(t)],t=Pi..2*Pi]]:
Sol:=Inscribed_Square(L);
Pic(L,Sol);

The procedure finds 6 solutions for a non-convex pentagon:

 L:=[[[0,0],[9,0]],[[9,0],[8,5]],[[8,5],[5,3]],[[5,3],[0,4]],[[0,4],[0,0]]]:
Sol:=Inscribed_Square(L,'s');
plots:-display(Matrix(3,2,[seq(Pic(L,Sol[i]),i=1..6)]),size=[300,200]);

For an implicitly defined curve, only one solution can be found:

L:=abs(x)+2*abs(y)-sin((2*x-y))-cos(x+y)^2=3:
Sol:=Inscribed_Square(L);
Pic(L,Sol);

               
See more examples in the attached file.

Inscribed_Square.mw

Hi again all,

prime numbers are fun for me.

see

pairs_of_prime_numbers_procedure_with_union_and_isprime.pdf

sorry, could not find the .mw file,

but the code is small, and easy to copy

this is fun for me, here in Keizer OR, USA

Party on, everyone

Best regards,

Matt

https://mattanderson.fun/

Hi Maplesoft Support / Community,

I've encountered a critical and bizarre bug involving Bits:-And correctness on large integers (~30 digits) derived from repeated integerdivq2exp operations.

• Maple 2023 (Linux x86_64)
• Maple 2025 (Linux x86_64)
• Maple 2025 (Windows x86_64)

The correctness of Bits:-And depends on the order of execution. 

(See attached common.mpl, bug_test2.mpl, bug_test3.mpl logic).

Case "Fail" (bug_test2.mpl):

1. Run operation (loops `integerdivq2exp`).
2. Print result num1 (semicolon).
3. Define num1_clean (hardcoded same value).
4. Bits:-And(num1) -> INCORRECT.
5. Bits:-And(num1_clean) -> INCORRECT.

Case "Pass" (bug_test3.mpl):

1. Define num1_clean.
2. Run operation (loops integerdivq2exp).
3. Bits:-And(num1) -> CORRECT.
4. Bits:-And(num1_clean) -> CORRECT.

The same behaviour can be observed in Worksheet mode using read.  (See worksheet_driver.mw)

But the result cannot be reproduced if not using read. (See worksheet_version.mw and worksheet_version2.mw)

Code below:

N := 2100:
n := 1000:
num := rand(0 .. 2^N)():
operation := proc(num, n)
    local q, k;
    q := num;
    for k from 1 to 2 do
        q := integerdivq2exp(q, n); 
    end do;
    q;
end proc:

read "common.mpl";

num1 := operation(num, n);
num1_clean := 1083029963437854242395921050992;

num1_clean_And_result := Bits:-And(num1_clean, integermul2exp(1, n) - 1);
num1_And_result := Bits:-And(num1, integermul2exp(1, n) - 1);

##################################

expected_result := irem(num1_clean, integermul2exp(1, n));

if num1 <> num1_clean then
    error "num1 does not match num1_clean";
end if;
print("num1 matches num1_clean");

if num1_And_result <> num1_clean_And_result then
    error "num1_And_result does not match num1_clean_And_result";
end if;
print("num1_And_result matches num1_clean_And_result");

if num1_And_result <> expected_result then
    error "num1_And_result does not match expected_result";
end if;
print("num1_And_result matches expected_result");

read "common.mpl";

num1_clean := 1083029963437854242395921050992:
num1 := operation(num, n):

num1_clean_And_result := Bits:-And(num1_clean, integermul2exp(1, n) - 1):
num1_And_result := Bits:-And(num1, integermul2exp(1, n) - 1);

##################################

expected_result := irem(num1_clean, integermul2exp(1, n));

if num1 <> num1_clean then
    error "num1 does not match num1_clean";
end if;
print("num1 matches num1_clean");

if num1_And_result <> num1_clean_And_result then
    error "num1_And_result does not match num1_clean_And_result";
end if;
print("num1_And_result matches num1_clean_And_result");

if num1_And_result <> expected_result then
    error "num1_And_result does not match expected_result";
end if;
print("num1_And_result matches expected_result");

As I have stated "a few times" here on Maple Primes, I've written a new book with Nic Fillion on perturbation methods.  The book will be published by SIAM early next year.  To help market the book, I sent several images to my editor who asked her team to make a desk calendar out of them.  The PDF for that is

here at this link to my web page at github

I had fun making the images, in Maple, and the QR code on the calendar links to a Maple Transactions paper that describes each of the images.  To save you struggling with your QR code reader, here is a link to that paper.

Best wishes for the season and for 2026.

Over the past year, I have spent a lot of time talking to educators, researchers, and engineers about AI. The feeling is almost universal: it is impressive, it is helpful, but you should absolutely not trust it with your math even if it sounds confident.

That tension between how capable AI feels and how accurate it actually is has been on my mind for months. AI is not going away. The challenge now is figuring out how to make it reliable.

That is where Maple MCP comes in.

Maple MCP (Model Context Protocol) connects large language models like ChatGPT, Claude, Cohere, and Perplexity to Maple’s world-class math engine.

When your AI encounters math, your AI can turn to Maple to handle the computation so the results are ones you can actually trust.

It is a simple idea, but an important one: Maple does the math and the AI does the talking. Instead of guessing, the AI can be directed to call on Maple whenever accuracy matters.

Model Context Protocol (MCP) is an emerging open standard that allows AI systems to connect to external tools and data sources. It gives language models a structured way to request computations, pass inputs, and receive reliable outputs, rather than trying to predict everything in text form.

Here is a high-level view of how MCP fits into the broader ecosystem:

MCP lets an AI system connect securely to specialized services, like Maple, that provide capabilities the model does not have on its own.

If you want to learn more about the MCP standard, the documentation is a great starting point: Model Context Protocol documentation

Here is a glimpse of what happens when Maple joins the conversation:

Depending on the prompt, Maple MCP can evaluate expressions symbolically or numerically, execute Maple code, expand or factor expressions, integrate or solve equations, and even generate interactive visualizations. If you ask for an exploration or an activity, it can create a Maple Learn document with the parameters and sliders already in place.

As an example of how this plays out in practice, I asked Maple MCP:

“I'd like to create an interactive math activity in Maple that allows my students to explore the tangent of a line for the function f(x) = sin(x) + 0.5x for various values of x.”

It generated a complete Maple Learn activity that was ready to use and share. You can open the interactive version here: interactive tangent line activity .

In full disclosure, I did have to go back and forth a bit to get the exact results I wanted, mostly because my prompt wasn’t very specific, but the process was smooth, and I know it will only get better over time.

What is exciting is that this does not replace the LLM; it complements it. The model still explains, reasons, and interacts naturally. Maple simply steps in to do the math—the part AI cannot reliably do on its own.

We have opened the Maple MCP public beta, and I would love for you to try it.

Sign up today and we will send you everything you need to get started!

My student, David Wei, has ported Andrew Hicks's MOISE package to Maple 2025:

GitHub - david-wei-01001/MOISE-for-Maple-2025: MOISE that is compatible with the newest Maple 2025 Engine

Regards,

Gerald Penn

The Autumn Issue is now up, at mapletransactions.org

This issue contains two Featured Contributions; a short but very interesting one by Gilbert Labelle on a topic very dear to my own heart, and a longer and also very interesting one by Wadim Zudilin.  I asked Doron Zeilberger about Wadim's paper, and he said "this is a true gem with lots of insight and making connections between different approaches."

The "Editor's Corner" paper is a little different, this time.  This paper is largely the work of my co-author, Michelle Hatzel, extracted and revised from her Masters' thesis which she defended successfully this past August.  I hope that you find it as interesting as I did.

We have three refereed contributions, a contribution on the use of Maple Learn in teaching, and a little note on my design of the 2026 Calendar for my upcoming SIAM book with Nic Fillion, as well.  All the images for the calendar were generated in Maple (as were most of the images in the book).

It's been fun to put this issue together (with an enormous amount of help from Michelle) and I hope that you enjoy reading it.

I would also like to thank the Associate Editors who handled the refereeing: Dhavide Aruliah, David Jeffrey, and Viktor Levandovskyy.

It is possible to construct a system of equations that defines all spheres that touch two smooth surfaces.

This includes all the spheres inscribed between these surfaces. The first two equations are surfaces,  x7, x8, x9 are the coordinates of the centers of the spheres, the remaining variables correspond to the coordinates of the points of contact. 
In the program, we inscribe a sphere between a cylinder and a sphere. An example of obtaining one of the infinite subsets of the solution to a system of equations is implemented. This solution is "responsible" for the equation f8.
INSCRIBED_SPHERES_CILL_FOR.mw

And one more example.

The recordings from Maple Conference presentations, including the workshops, are now available on the conference website.

Thank you to all those who attended or presented, you made the conference a great success!
We hope to see you all again next year.

Kaska Kowalska
Contributed Program Co-Chair

The Schatz Mechanism should move like this

However, with the default solver settings it froze after a few seconds in a planar link configuration. To make it run, I played around with advanced solver settings. Here is one attempt that went nuts:

(More solver settings for strange behavior can be found here: Schatz_Linkage.msim)

Some people might find this amusing. Of course, it is less fun when the initial plan was to spend an hour just for fun with a simple model (an hour is a fair estimate for similar simple looking models in MapleSim). The immediate reaction when seeing such simulation results is to blame the software for being either buggy or incapable. In this case, however, this was not the case, but identifying the root cause was not obvious.

The Schatz mechanism is a so called closed-loop mechanism where the links of the mechanism form a loop (the ground in the model closes the loop). In general, building and modeling mechanisms with loops is less straight forward than thought. Without a-priory knowledge or help (either by documentation or software hints) users can quickly find themselves in a situation of desperate trial and error. What was easy with other models can become a frustrating experience with unsatisfactory outcome. This happened to me on various occasions.   

What makes closed-loop mechanisms more challenging?  After resting for a long time on my virtual pile of unanswered questions, it turned out that the model, on top of being a closed-loop mechanism, is ill-conditioned: The Schatzmechanism is an over-constrained mechanism that is only mobile for certain geometric parameters. MapleSim can simulate such over-constrained mechanisms, but this can be a balancing act for the solver.

Who could have known this? A knowledgeable expert might say that users who do not know what they are doing should not use the software. But how to become aware of over-constrained assemblies when building and running a model in MapleSim does not require to be an expert?  In this case the geometry was taken from a reference that sets the length of the ground link to Ö3. Model build, assembly and simulation instantly worked … but not for an extended time span.

In retrospect, everything is clear. Models that do not assemble do not fit together. Models that freeze in motion “jam numerically”. Linkages and joints of closed-loop mechanisms made of infinite stiff components may not fit together in all geometrical configurations. During runtime, after successful assembly, a stiff model can make a simulation sensitive to numerical errors. This does not mean that the user is dealing with a so-called numerical stiff problem that can be addressed by using stiff solvers. In this case, stiff solvers could not prevent sudden freeze or inversion of movements.

The only remedies that work for infinite stiff and over-constrained mechanisms are the ones that work also in real life. By either introducing mechanical play or elasticity in supports, joints and links, the simulation becomes robust. Numerically, for this case where none of the many advanced solver options made a difference, a simple increase of the relative error in the standard simulation settings worked.  This remedy could be described as introducing more numerical play. Interestingly in a completely different approach of animating a Schatzmechanism @one man also needed to introduce “deformations” in his simulation to make it work.

The Schatzmechanism is of little commercial interest and can therefore be shared. Is it a rare case of successful assembly and freeze during runtime or is it more frequent that users run into similar problems? Only MapleSoft can tell, but in the latter case it could make sense that MapleSim supports the user. I see several possibilities for that:

• A more prominent mention in the documentation that kinematic loops require caution could raise awareness.  
• Algorithmically detecting kinematic loops and informing the user that closed loops can be potentially over-constrained in certain geometric configurations.
• (If possible, analyzing the Jacobian in the frozen configuration might give better hints than solver messages during runtime can provide. The attached model gives the hint with MapleSim 2025.1 that the error tolerance might be too tight, but no indication why.)
• Implementing the mobility formula, analyzing closed loops and issuing a warning when the mobility M is less than 1 (meaning no degree of freedom)

The latter option sounds appealing. However, the degree of freedom calculated by the mobility formula only provides a necessary but unfortunately not a sufficient condition for mobility.  For example, connecting a prismatic joint coaxially to another increases the mobility by one but does not add to the mobility of a mechanism. This means that an advanced algorithm must take the orientation of joints into account to determine the effective degrees of freedom. On the other hand, the Schatzmechanism and some other mechanisms have a mobility of M=0 but can be mobile for certain geometries.

Should Maplesoft implement mobility analysis or are CAD tools that offer some sort of mobility analysis more suitable? In my opinion, from a conceptual point of view, it would be beneficial and faster to have this support already in MapleSim before going into details.

Should the user refrain from modeling infinite stiff mechanisms? I do not think so because they are useful in the context of deriving (analytical) forward and inverse kinematics. Furthermore, there are more mechanisms out there that are mathematically, according to the mobility formula, immobile but useful in daily life. The telescopic fork is a prominet example.

Final note for math enthusiasts:

The Schatzmechanism (invented by Paul Schatz) is a byproduct of the inversion of a cube. Recalling that the diagonal of the unit cube is Ö3 gives a hint of why the Schatz mechanism becomes mobile for this parameter. Also related to the inversion of a cube is the oloid: a solid with a developable surface that touches with its entire surface a flat surface when rolling. The oloid and the Schatz mechanism are closely related, which can be appreciated from this video.

Maplesoft continues to bring technology, collaboration, and learning together. Here’s some of the exciting industry news from the world of web converting and high-precision manufacturing lines, and what’s new with MapleSim for Web Converting Systems software.

How is MapleSim helping web converters and manufacturers?

From EV batteries to flexible packaging and medical films, industries that rely on thin web materials are advancing at remarkable speed. To keep pace, engineers need tools that let them model, simulate, and optimize every detail of their process with accuracy and confidence. Processes that once relied on intuition and trial-and-error are now guided by advanced modeling and simulation, such as MapleSim.

Using MapleSim simulation, engineering teams can perform process validation testing virtually - saving time and money compared to physical testing. The virtual models are used to explore and accelerate production — and the new release of MapleSim delivers a powerful set of features to make that possible.

What’s new in the latest MapleSim release?

The new release (available today) enhances MapleSim’s ability to answer “what-if” questions about industrial systems, easily review and compare results, and find strategies to improve production.

For converters and web material manufacturers, it is now even easier to create models of roll-to-roll systems. The updates to MapleSim for web converting systems include pre-built components for modeling spans and applying control during rewinding and matching tension profiles with PLC settings. There is also a new Utilities section to help users to handle sensor data and perform common calculation tasks.

We have just released updates to Maple and MapleSim.

Maple 2025.2 improvements include fixes to print layout, PDF export, tooltips for keyboard shortcuts, Plot Builder, and more. We recommend that all Maple 2025 users install this update. This update is available through Tools>Check for Updates in Maple, and is also available from the Maple 2025.2 download page, where you can find more details.

At the same time, we have also released an update to MapleSim, which includes enhanced tools for comparing models and analyzing simulation data, and improved runtime performance for MapleSim connectors.You can find more information on the MapleSim 2025.2 download page.