Categories

Upgrade your vehicle with premium Car Wraps in Ottawa. At Wrap Senators, we deliver high-quality car wraps Ottawa drivers trust for full colour changes, paint protection, and bold custom styling.

Our complete wraps use premium cast vinyl from 3M, Avery Dennison, Hexis, Inozetek, KPMF and Vinyl Frog to cover every panel edge to edge, protecting your original paint while transforming your vehicle's appearance. When a project calls for a colour or finish those lines do not carry, we can source other films for that specific job.

We specialize in custom car wraps Ottawa, including matte, gloss, satin, chrome, and carbon fibre finishes. From luxury car wraps to eye-catching car wraps and graphics, our team handles both personal and promotional projects. Need branding? We also create professional commercial vehicle wraps, fleet wraps, and custom printed vinyl wrap designs that turn your vehicle into a mobile advertisement.

We provide expert truck wraps, pickup truck wraps, and SUV wraps, along with motorcycle wrapping service and durable boat wraps near me solutions.

Pricing for custom car wraps cost, truck wrap price, or suv wrap cost depends on vehicle size and design complexity. We offer transparent quotes and precision installation for long-lasting results.

For premium Full Vehicle Wraps in Ottawa, trust Wrap Senators to deliver flawless craftsmanship and standout style.

In my third year as a computer science undergraduate at a university in Hong Kong, I began studying the mathematics department’s ordinary differential equations courses on my own. I was already comfortable programming in C and Java, and I had long enjoyed mathematics and physics. ODEs gave me a question that brought those interests together. Working through examples in Kamke’s handbook, I kept encountering substitutions and rearrangements that were easy to verify once someone showed them to me, but hard to discover in the first place. Could a systematic theory explain when those tricks work and how to find them?

Discovering Maple changed how I thought about that question. Through its documentation and the work of E. S. Cheb-Terrab and others, I learned how Lie symmetries, differential invariants, and first integrals can make parts of ODE solving systematic. I also began studying Liouvillian integrability, invariant algebraic curves, and differential Galois theory. I found myself asking what structure an equation reveals, even when its solutions resist a familiar closed form.

Abel equations became a natural place to look. Their solution structure is rich, and differential invariants under changes of the independent variable and affine changes of the dependent variable give a way to compare equations that look quite different. The classification of integrable Abel equations by Cheb-Terrab and A. D. Roche made that idea concrete: equations scattered across different sources could be recognized as members of the same class. I began to wonder how far we could take this if the substitution itself were allowed to be nonlinear.

I started working systematically on this inverse problem around the first year of graduate school. Given a rational first-order equation y' = M(x,y)/N(x,y), can we recover a nonconstant rational substitution u = A(x,y)/B(x,y) that leaves x unchanged and makes u' a polynomial in u? If the reduced equation belongs to a known integrable class, the substitution gives us a route to solving the original equation. Even when it does not, a successful reduction exposes structure that is hard to see in the original coefficients.

My first paper in Maple Transactions treated the nondegenerate case, where the relevant factors survive when the rational equation is put in lowest terms. The software from that work was subsequently licensed to Maplesoft. My second paper studied what happens when factors cancel. It develops a practical bounded search as well as a full algorithm that does not require the user to supply a degree bound for the transformation.

The insight I found most rewarding was that cancellation can point to an invariant algebraic curve of the original system. In the cancellation setting treated in the paper, a factor that disappears from the reduced fraction can encode an algebraic solution curve. Recovering it can therefore give us two things at once: a substitution that simplifies the ODE and geometric information about the original vector field. Invariant algebraic curves can be difficult to find directly. Obtaining one as part of a reduction is a good example of what I value in Maple’s approach to ODEs: a symbolic computation can tell us something about the equation even before we ask for its general solution.

The cancellation case is also the more expensive one. When the initial constraints leave several possibilities, the algorithm may have to fall back on nonlinear algebra. In discussions with GPT, one suggestion gave me a particularly useful way to approach that bottleneck: expand the reduction identity locally at a pole, then use the first few terms—the jet—to derive linear constraints on the unknown numerator.

Those constraints can be tested at a regular rational value of x, using exact arithmetic. A branch whose necessary conditions are inconsistent can be discarded before costly symbolic elimination. For a surviving branch, the symbolic calculation still takes place over the rational function field. If the linear constraints determine a unique normalized numerator, the implementation can recover the target coefficients and verify the substitution directly. Otherwise, it retains the nonlinear fallback. The main gain is that expensive computations are reserved for branches that survive cheaper tests; the speedup depends on how much those tests narrow the search.

Maple source (.mpl):GeneralizedAbel_Maple.txt

For inputs over the rational numbers, ReduceHigher is sound and complete for target equations of actual degree n > 2, with the independent variable unchanged and no user-supplied bound on the transformation degrees. Every reported reduction satisfies the exact differential identity, and a completed search can rule out reductions in this class. That guarantee does not extend to the general Riccati case n = 2.

Load the source with read and pass the numerator and denominator of the original slope:

restart:
read "GeneralizedAbel.mpl":

M := (y+x)^5 + (x*(y+x)-2)*(y-1)^2:
N := (y-1)*(y-x-2):

t0 := time():
R := GeneralizedAbel:-ReduceHigher(M, N, x, y, u):
elapsed := time()-t0:

R["status"];
R["transformation"];
R["equation"];
R["residual"];
elapsed;

In one Maple 2026 run, the search returned FOUND in 0.171 seconds of CPU time, excluding source loading. The transformation and reduced equation were:

u = (x^2 + y^2 + 2*x)/(y - 1)
u' = (u + 2*x)^3 + x*(u + 2*x) - 2

The exact residual was 0. The returned substitution is a normalized form of v = (y+x)^2/(y-1), with v = u + 2*x. In this form, the cancelled factor y+x also has a geometric interpretation: the line y = -x is an invariant algebraic solution curve of the original equation.

I plan to attend ISSAC 2027 in Tsukuba, Japan, July 12–15. If you work on ODEs, symbolic computation, or invariant curves, I would love to meet you there and hear what examples or questions you would bring to this problem. I would also like to share some of the projects related to Maple that I am currently working on.

I hope the Maple community will see rational reduction as a symbolic computation problem in its own right. Finding a change of variables, deciding whether one exists in a specified class, and understanding what it reveals about a vector field are worthwhile goals—even when the next step is not a call to dsolve.

— Shaoxuan Huang

Ask any engineer where the time goes in a modeling project, and the answer is rarely "the math."

It's everything around it: hunting for commands, opening help in another window, checking a plot, finding your place in the model again. Each interruption is small. Together, they can turn an afternoon of modeling into a week.

MapleSim 2026 was built around that idea. From the first install to the final result, it keeps what you need right where you're working.

Getting started is now simpler than ever. MapleSim, all its toolboxes and the Maple engine are now delivered in a single installer, so one installation provides everything needed to get started.

Context-sensitive hover bars display the most frequently used commands next to the current selection, and consolidated menus group related commands together. These changes reduce the steps required to build and modify models.

A new split pane, which can be arranged beside the diagram or opened in a separate window, updates with each selection to display the component's help page, its Modelica code, or live plots of its variables in the time or frequency domain. Engineers can review component details without leaving the model.

The Optimization app now displays live system plots and a time history of the objective function during execution, allowing engineers to assess convergence and intervene early when needed. The in-product apps have also been redesigned with a more compact layout for use alongside the split pane.

FMI import and export now support string and discrete parameters, inputs, and outputs. The MapleSim CAD Toolbox supports the latest formats from Catia® V5, SOLIDWORKS®, Creo®, NX™, Inventor®, Solid Edge®, Parasolid®, and other CAD tools. MapleSim 2026 also supports the latest Maple interface, including ribbons, the AI Assistant, and improved performance.

Building a web line model involves many components, each with its own connections and parameters. The new Web Handling Model Creation App automates this process. Starting from a tabulated data file describing the line, the app validates the data, calculates wrap angles, span lengths, and roller mass and inertia, and generates the complete MapleSim model. Engineers can then proceed directly to adding drives, dancers, and control loops to analyze line performance.

New components extend modeling coverage to more of the processes found on real lines:

• Noncircular winding and unwinding, for rolls that are not perfectly round

• Delamination, where one web separates into two

• Web-on-web friction, for two webs running through a nip roller together

• Tendency drives, using the new Roller Shaft component

The library is also easier to use and delivers more accurate results. A reorganized Rollers sub-palette groups components into Rollers, Nip Rollers, Multi-Web, and Parameters. Sequential and S-Wrap Nip Rollers simplify S-wrap configurations, and a per-unit option adds flexibility to drives and controls. Improved handling of span tension loss and special nip roller configurations further increases accuracy.

MapleSim 2026 adds new components that capture more real-world detail in machine models.

• Ropes and Pulleys Library: Variable Winch 3D allows engineers to define the shape of the winch drum. Pulley Edge models side contact between the sheave and the rope, and Pulley Multi-Turn models multiple rope turns for added friction, complete with visualization.

• Multibody Library: A new Gear Forces sub-package provides simplified models for spur, helical, bevel, and crossed gear pairs, along with a ratchet wheel model.

• Directional Control Valve app: The app now creates pneumatic valves in addition to hydraulic valves.

MapleSim 2026 reduces the time spent navigating the software and increases the time available for what matters most: understanding and improving designs.

To try MapleSim 2026, start your free instant evaluation today. For a complete overview of the release, visit What's New in MapleSim 2026.

Did you know that October 24th, 2026, is a very special day for us math lovers? Writing the date as 10/24/26, the date creates the following Pythagorean triple:

10² + 24² = 26²

Making it a Pythagorean Theorem Day! In fact, it is the very last one of the century (the next being in 2105). Over the years, our Maple community has been exploring some incredibly interesting ways of visualizing, proving, and applying one of math's most famous theorems!

To celebrate this great day, I thought we could revisit some of our coolest posts on the topic.

Since we are celebrating a pythagorean triple day, the Maple Learn post on Generating Pythagorean Triples is a great way to explore the theorem. Any three positive integers that satisfy the pythagorean formula are considered one of these triples (the most popular being 3, 4, and 5). The generation of these values can be looked at from both a geometric and algebraic perspective!

One of the coolest things about the Pythagorean Theorem is that we are still discovering new ways to prove it! Traditionally, a geometric method was used to prove the theorem, as can be seen in this Maple Learn post. But in only 2023 two high school students, Calcea Johnson and Ne'Kiya Jackson, presented a new trigonometric proof for the Pythagorean Theorem. 

This was incredible since most trigonometric proofs are based upon the theorem itself, so being able to prove it without these was very impressive! You can explore their approach in Johnson and Jackson's Proof of the Pythagorean Theorem, or read more about it in the MaplePrimes post New Proof of the Pythagorean Theorem.

This even inspired some mathematical artwork in Maplesoft's art competition, Paige Stone created an embroidery piece Infinite Similar Triangles based on the Johnson-Jackson triangle construction. What a fun reminder that math is just as creative as it is logical!

The Pythagorean Theorem is mostly thought of as a right triangle problem, but it is so much more than that!

Consider the Staircase Paradox. If you keep decreasing the size of steps to a staircase, the shape begins to look like a straight diagonal, but the length does not approach the length of that diagonal! The Pythagorean Theorem helped us uncover the surprising behavior behind these limits. 

Another interesting application is in Finding the Shortest Path Between Two Points, where the theorem can be applied to arc length calculations. This theorem can show up in some unexpected places! Below is an example of some curves the Pythagorean theorem can be used to calculate!

From geometry, to algebraic and trigonometric proofs, mathematical art or simply a good paradox, the Pythagorean Theorem can be explored endlessly. Do you have a favorite proof, application, or derivation from the Pythagorean Theorem? Try to appreciate it a little more on this day, since we won't have another for a while!

Can the Maple community make exact integrability computations substantially faster?

For a planar polynomial vector field
[
D=A(x,y)\partial_x+B(x,y)\partial_y,
]
a Darboux polynomial is a nonconstant polynomial (f) satisfying
[
D(f)=Kf
]
for a polynomial cofactor (K). These invariant algebraic curves are fundamental building blocks in the search for first integrals and integrating factors.

The subject reaches back to Darboux’s nineteenth-century work and connects with the Prelle–Singer and Singer theories of elementary and Liouvillian integrability. Turning these structural results into effective, reliable programs remains an important computational problem. Given Maple’s long tradition in symbolic differential equations, MaplePrimes seems an ideal place to invite a practical challenge.

The starting point

Bostan, Chèze, Cluzeau and Weil developed algorithms for bounded-degree rational first integrals and Darboux polynomials using local solutions and extactic constructions. Related ideas appear in Chèze–Combot’s algorithms for symbolic first integrals and Combot’s work on symbolic integration of planar differential foliations. These works include Maple implementations.

They provide powerful mathematical frameworks, but their implementations can encounter substantial practical difficulties:

• coefficient growth in exact truncated series;

• expression swell in parameter-dependent extactic matrices, polynomial minors and Smith-form computations;

• expensive matrix assembly, exact linear algebra and reconstruction.

The bottleneck depends on the input and the implementation. Improving the kernel solver alone may achieve little when exact series construction dominates.

Our current baseline

We have implemented practical optimizations within these frameworks: jet-based constructions, truncated-series arithmetic, avoidance of full Smith-form computation in the Darboux code, modular filtering and linear algebra, rational reconstruction, and exact verification.

These are our current best-performing implementations, offered as reproducible baselines for further improvement—not as a claim of universal optimality.

For Darboux polynomials:

restart:
read "PATH/TO/FastDarboux.mpl":

A := 1:
B := 4*x^3 + y - x^4 - 1:
N := 4:

R := FastDarboux:-All(A,B,N,x,y):
R[status];
R[curves];
R[rational_curves];

The records in rational_curves are pairs [f,K]. Algebraic coefficient extensions are represented in curves. The status "finite_complete" certifies complete finite enumeration within the stated scope; rational-first-integral and other exceptional cases have separate statuses.

A single-section calculation is available through:

R := FastDarboux:-Partial(A,B,N,0,x,y):

This searches using the section (x=0); its scope must not be confused with complete enumeration.

For the Liouvillian integrating-factor benchmark:

restart:
read "PATH/TO/Combot.mpl":
read "PATH/TO/slow_example.mpl":

st := time[real]():
R := IntegratingFactor(B/A,[-1,0],27):
time[real]() - st;

The benchmark file supplies (A,B). The implementation prints a completion status.

For this example, on our Maple 2026 test system, the complete call took about 123 seconds:

The returned integrating factor was independently verified by exact identities. These measurements describe one benchmark, not a general complexity claim.

Source code: Source code-Huang 
Documentation and mathematical scope: Documentation-Huang 
Benchmark inputs, environment and logs: Benchmark-Huang

The challenge

Improve end-to-end wall-clock time and memory use while preserving soundness and completeness for an explicitly stated bounded problem.

A better asymptotic bound is welcome, but it is not the primary objective. In exact symbolic computation, a field operation has no fixed machine cost: coefficient sizes, normalization, intermediate representations and data movement can outweigh an attractive exponent.

Technical improvements and well-designed heuristics are especially welcome. Possible directions include finite-field series construction, better precision management, adaptive reconstruction, structured linear algebra, improved candidate selection, or entirely different approaches.

Heuristics are welcome when their role is explicit: a failed heuristic must not silently become a proof of nonexistence. Likewise, verifying every returned curve proves soundness, but does not by itself prove completeness.

Please state degree bounds and assumptions, distinguish “no solution within the bound” from “inconclusive,” and handle rational-first-integral or infinite-family cases explicitly. This challenge does not assume that bounded searches settle unrestricted Liouvillian integrability. The current integrating-factor code also does not claim to return a minimal representation.

For performance comparisons, please include the whole computation, including preprocessing, series, reconstruction and certification, and compare tasks with the same mathematical scope.

AI tools have made remarkable progress in mathematical reasoning and programming. This is a concrete opportunity to use them on a longstanding computational problem. Contributions from anyone are welcome, with or without AI assistance: Maple code, compiled backends, mathematical arguments, counterexamples, profiling observations, or small improvements that make an important difference.

Please post suggestions, implementations, benchmarks and supporting arguments directly in the comments. The goal is a faster, reproducible and mathematically trustworthy solver.

For those who are familiar with the long history of the Maple Conference, you’ll know that we vary the format from time to time, and for the next conference, we'll be trying something new!

The next event will be a user conference, strongly focused on enabling Maple users to get the most out of Maple, increasing their knowledge and abilities through a series of technical talks by Maple experts. We’ll release more details later, but our main goal is to engage with and support the many customers who love Maple and want to learn how to do even more with it. This event will be held in the spring of 2027, which we hope will be a convenient time for those who find it difficult to attend a fall event.

Another aspect of past conferences has been the opportunity for users to share their work with the Maple community. We'd like to remind you that the Maple Transactions, an open-access online journal, is an ideal place to publish your work, and you can see an overview of the journal in this short video. If you prefer a less formal venue, we encourage you to post right here on MaplePrimes to share your work and interact with the community.

We will share more details as we get closer to the event. For now, we just wanted to give you an idea of the plans, as we know that many people look forward to the Maple Conference and expect to hear from us around this time.

The Maple Flow Skill for AI coding assistants lets you

• generate Maple Flow worksheets from a prompt or source material
• analyze Maple Flow worksheets, and pull out the equations, data and and definitions
• share Maple Flow worksheets by generating code or executables

I demonstrate what you can do with the skill in this video

Get the skill here, and use it with Claude Code, Codex, Antigravity or Github Copilot.

I tried to copy a snippet of a maple command from a worksheet and paste it elsewhere in the worksheet and it was transformed into document form. I could not figure out how to fix that.It was worthless to me. For example, in the command I had "eval(f, [y=1,d=3])" and it became f| with the subscript y=1,d=3.

Also, I wrote "parametr" in a procedure and Maple rejected the command with a vague complaint. OK, my bad; garbage in garbage out, parameter not parametr, etc. BUT this is 2026! Autocorrect features have been around for years. Underlining of strange spellings are standard on word processors, phones , etc. Can't Maple catch up? 

I am delighted to share that the ExaktAI Workspace now also provides a full-featured mathematical document interface for Lean, the theorem prover and proof assistant, integrated directly with computer algebra system (CAS) computation.

The Workspace, including its Lean integration, is in free beta testing and open to everybody.

Lean files (.lean) open as Lean documents, proofs are checked step by step with goals shown under each step, CAS computations can be inserted inside proofs, and a class of CAS results can be turned into Lean theorem candidates that Lean then independently checks.

The Workspace also includes a Lean tutorial, intended to make this accessible to users who are not yet familiar with Lean syntax and workflow.

CAS computations can be inserted between Lean proof steps. A class of CAS results can also be turned into Lean theorem candidates that Lean independently checks.



Edgardo S. Cheb-Terrab
ExaktAI, Canada
Research Fellow Emeritus at Maplesoft.

The former Maple UI displayed shortcut-keys in the menu entries. There was no need to consult the help system and good overview of possible menu control alternatives was provided.

In the new ribbon interface, such hints are not given anymore (if I am not mistaken).

Suggestion:
The information of shortcut keys could be added after the mouse-over text. For example Crtl+O after "Open a file"

 

For me, attaching the shortcut-key to the corresponding menu item is the most intuitive way to look up this information. Adding text is probably less invasive then graphical design changes, hence this pragmatic suggestion.

Alternatively, AI could provide the information but simple prompts (like "shortcut to open a file in Maple" or "list all keyboard shortcuts for Maple under Windows") did not work for me. A waist of time, credits and energy for nothing. Somehow it is difficult for to todays AIs to identify that there is a help page (not easy to find for beginners and me in Maples help system, IMO) that contains all information needed:
?worksheet,reference,hotwin

Mathematics and physics are evolving disciplines. AI is increasingly becoming an active participant in that evolution, producing results at a speed and scale that are difficult to follow without appropriate computational tools.

In the ExaktAI project we are addressing two related issues: the reliability problem of AI mathematics through computational validation, and maximizing human participation in checking, understanding and extending the results.

For the latter, we developed the ExaktAI Workspace.

The Workspace is a full computational-mathematics document environment in which one can follow, inspect, modify and extend AI-generated mathematics, or simply do the mathematics directly. Of particular relevance here, the Workspace can run Maple directly when Maple is installed.

The public beta is now open. I would be particularly interested in feedback and suggestions, both about the Maple integration and about the broader ideas for keeping us, the humans, actively involved and increasingly participating in AI-mathematics developments.

Update, September 27: the Workspace now also provides a document interface for Lean, the theorem prover, with CAS computations inside proofs; see "The Lean theorem prover" below.

Edgardo S. Cheb-Terrab
ExaktAI, Canada
Research Fellow Emeritus at Maplesoft.

I am pleased to announce that Volume 6 Issue 2 of Maple Transactions has now been published.  In some ways it is the largest issue we have yet published, because it leads off with a magnificent paper by Gilbert Labelle, which clocks in (with its appendix) at over a hundred pages.  Professor Labelle is one of the world's best combinatorialists, and this paper is (in my mind) beautiful, and well worth the effort to read it.  The illustrations are also illuminating, and excellent.  

David Jeffrey and I put in two related papers, and together they clock in at just over fifty pages; and well I have to say there's some neat illustrations there, too.

But the real contributions of the issue are, first, Bill Bauldry's Simulation of the Enigma, in Maple (a worksheet included by popular demand!) and the five refereed papers.

The cover image is a picture from the Maplesoft reception at the International Conference on Mathematical Software held in Waterloo in July, which I reproduce here, just for fun.

Dear MapleSoft Team,

I am writing to share some feedback regarding a new feature introduced in Maple 2025. Specifically, when typing ^, /, or __ followed by a number or symbol and then entering another operator (such as +), the operator is automatically inserted on the baseline.

While I understand this "smart baseline behavior" may be useful for some users, I personally find it disruptive and counterproductive. It often interferes with my workflow rather than improving it.

May I suggest adding an option that allows users to choose whether to enable or disable this feature? Providing such flexibility would accommodate both those who appreciate the behavior and those who prefer the previous input style.

Thank you for considering this feedback. I hope this suggestion can help improve the user experience for a wider range of Maple users.

Add a couple of variables to a polynomial system and the difficulty climbs fast. Maple 2024 helps here in one specific way: RootFinding:-Isolate handles complex solutions of multivariate systems.

Take this one:

sys := [
  x + y + z = 0,
  x*y + y*z + z*x = 1,
  x*y*z = 1
]:

RootFinding:-Isolate(sys, [x,y,z], complex);

Previously you would break that down yourself into a chain of single-variable equations. Now you hand it over whole.

fsolve changed too. For univariate polynomials above degree two it calls RootFinding:-Isolate by default. There is also a PW method, which isolates and approximates complex roots faster in a lot of cases.

Worth understanding what isolation actually does: it locates regions containing roots first, then refines the approximations inside them. That ordering matters when roots cluster tightly or sit in the complex plane, exactly where plain numerical root-finders start returning garbage or grinding.

One thing I’ve been experimenting with recently is how much the form of an expression can affect Maple’s performance.

For example, two mathematically equivalent expressions can behave very differently when passed to simplify, solve, dsolve, or numerical procedures.

A useful workflow is to simplify and restructure the problem before asking Maple to do the expensive part.

For example:

restart:

expr := (x^2-1)/(x-1):

simplify(expr);

gives a much simpler expression, but in larger problems the same idea can make a surprisingly big difference.

I’ve also found it useful to inspect intermediate expressions rather than immediately running a large command:

interface(showassumed=0):

simplify(expr, symbolic);
factor(expr);
expand(expr);
collect(expr, x);

The interesting part is that Maple isn't necessarily “slow” because the underlying mathematics is difficult. Sometimes it is simply being asked to work with a representation that hides the structure of the problem.

For large symbolic calculations, I now tend to think of Maple as having two stages:

1. Prepare the mathematics

Reduce, factor, substitute, collect terms, exploit assumptions, and remove unnecessary complexity.

2. Let Maple perform the expensive computation

Only after the expression has been put into a useful form.

This seems particularly important with large nonlinear systems, symbolic integration, and differential equations.

A small change in representation can sometimes turn a calculation that takes minutes into one that takes seconds.

I’d be interested in seeing more examples where Maple's performance was improved simply by changing the mathematical representation of the problem.