MaplePrimes Posts

MaplePrimes Posts are for sharing your experiences, techniques and opinions about Maple, MapleSim and related products, as well as general interests in math and computing.

Latest Post
  • Latest Posts Feed
  • When we first launched Maple Learn in January, there were only a handful of examples in the Example Gallery. Today, due to customer requests, we have 57 examples and the number grows every week. You can check out the gallery here:

    The gallery is full of both practical and fun examples showing how you can use Maple Learn to work with all kinds of math. One great example is this worksheet on Logarithmic and Archimedean spirals made by our Sales Account Manager, @Oliver K. You can learn a bit about each type of spiral and adjust the sliders to see how the different parameters change the visualization. It’s a great tool for introducing students (or anyone who likes cool graphs!) to these types of spirals and for helping them understand the math behind them.

    We’ve got a whole team of people, led by Senior Architect @pchin, who are working every day to make more examples like these. If there’s something you’d like to see, leave us a comment! We’d love to hear your ideas.

    If you’re feeling inspired by all these examples and want to try your hand at creating something of your own using Maple Learn, check out the “How to Use Maple Learn” section at the end of the example gallery. Here you’ll find a collection of worksheets that will take you through the basic features of Learn, including “Using Sliders”, “Difference Between Equations and Assignments”, and “What Does the Light Bulb Do?”. With all this knowledge at your fingertips, you’ll be all set to create to your heart’s content!

    Equation labels are great!

    I use them extensively to produce textbook style documentation that is understandable for non-Maple users. Even if Maple input is not hidden, documents look much cleaner since auxiliary names and the assignment statement “:=” do not have to be used most of the time.

    Suggestions to improve Maple 2021 equation label functionality (in order of preference):

    • In a text passage or Maple input: Double click on a label reference to open the insert label dialogue (crtl-L) in order to change the reference (instead of deleting the reference and inserting a new reference).
    • Right click on an equation label to hide it with the context menu. Or right click on the output and have a “show/hide label" option.
    • After a document is finished, input is hidden and before printout/export is produced: A function that hides/shows all labels that are not referenced in text passages.
    • A search function for equation labels in a document, or alternatively: a pallet simliar to the variable pallet to manage labels.
    • Labels inside a text passage that refer to executable math with toggled input. This would allow the definition of expressions inside a text passage and use them in subsequent calculations. Example for a text passage: “If we insert for the mass m=15 kg in equation (33), the frequency response looks as follows:" plot(subs(label_of(whatever has been attributed to m=15kg),(33)),plot_range). This would reduce redundant entries in the document and potential mismatch between text and calculation results.
    • Renaming of single labels (i.e. assigning an alias) either by right click on the label or by a pallet.
    • Labels for non-executable math inside a text passage for further use in other text passages or later insertion in executable math.


    • There is another (not documented?) feature that is very handy: Double click on an equation label inserts the equation label at the cursor position. A nice time saver.
    • Only recently I found out that single equation labels can be hidden/removed using Format>Equation Labels>Selection. Since this option was always grayed out, I could not make sense out of it, because the text was not self-explanatory to me.  Instead of Format>Equation Labels>Selection a more self-explaining menu entry would be desirable. “show/hide selection” would already better describe the action behind the menu item. However, it is still not intuitive to select output in order to make equation labels disappear (that are by the way not highlighted in blue by the selection process when only a single output/execution group is selected). There are many reasons that could make a change to self-explaning menu items not that straight forward as it sounds. In this case a mouse-over is always helpful to get more explanations on a button or a menu item. Alternatively and probably better: It would be more straight forward to select or click onto labels to manipulate them. This of course only works for one label at the time, which in my case is the most common use case.
    • Equation labels are unique. They enable a work and documenting style that other math tools do not provide. If used consistently, they provide a new level of abstraction where explanatory text and computation can be combined in way that a mathematical interpreter (human or a smart machine) could proof results using only textbook style documents as input (e.g. pdf scans). At least, this is theoretically possible. However, I have noticed that many examples from users do not make use of equation labels. They are still pretty much done in a traditional programming style where loads of unnecessary variables are used. This is understandable since many people start mathematical problem solving with the aid of computers by programming. So new users to Maple use Maple pretty much the same way they were trained.
    • I am fully aware that there are many applications where equation labels are not the most efficient way of producing a result. But producing a result is different from documenting results or even documenting a mathematical proof.


    Some of you know me from my occasional posts on Maple’s typesetting and plotting features, but today, I am here in my new role as co-chair (along with Rob Corless of Western University) of the 2021 Maple Conference. I am pleased to announce that we have just opened the Call for Presentations.

    This year’s conference will be held Nov. 2 – Nov. 5, 2021. It will be a free virtual event again this year, making it an excellent opportunity to share your Maple-related work with others without the expenses and inconveniences of travel.

    Maple Conference 2021 invites submissions of proposals for presentations on a range of topics related to Maple, including Maple in education, algorithms and software, and applications. All presenters will be given the option of submitting a full paper, which will undergo peer review, and if accepted, be included in the conference proceedings.

    Presentation proposals are due June 1, 2021.

    You can find more information about the themes of the conference, how to submit a presentation proposal, and the program committee on Maplesoft Conference Call for Presentations.

    Registration for attending the conference will open in June. Another announcement will be made at that time.

    I sincerely hope that all of you here in the Maple Primes community will consider joining us for this event, whether as a presenter or attendee.

    The site contains free books in English and Russian along with software created under the guidance of the main author prof. V. Aladjev in such areas as general theory of statistics, theory of cellular automata, programming in Maple and Mathematica systems. Each book is archived, including its cover and book block in pdf format. The software with freeware license is designed for Maple and Mathematica.

    CMRB is defined below. See

    Starting by using Maple on the Inverse Symbolic Calculator, with over 21 years of research and ideas from users like you, I developed this shortlist of formulas for the MRB constant.

    • CMRB= eta equals enter image description here

    That is proven below by an internet scholar going by the moniker "Dark Malthorp:"

    Dark Marthorp's proof


    • eta sums denoting the kth derivative of the Dirichlet eta function of k and 0 respectively was first discovered in 2012 by Richard Crandall of Apple Computer.

    The left half is proven below by Gottfried Helms and it is proven more rigorously considering the conditionally convergent sum,enter image description here below that. Then the right half is a Taylor expansion of η(s) around s = 0.



    it has been noted that "even though one has cause to be a little bit wary around formal rearrangements of conditionally convergent sums (see the Riemann series theorem), it's not very difficult to validate the formal manipulation of Helms. The idea is to cordon off a big chunk of the infinite double summation (all the terms from the second column on) that we know is absolutely convergent, which we are then free to rearrange with impunity. (Most relevantly for our purposes here, see pages 80-85 of this document, culminating with the Fubini theorem which is essentially the manipulation Helms is using.)"

    argrument 1 argrument 2

    I’m excited to announce the launch of a new math tool called Maple Flow. Here, I’ll outline our motivation for developing this product, and talk about its features.

    A large fraction of Maple users are professional engineers .

    All use Maple, but very few say that they do math for a living, in much the same way a plumber wouldn’t say they use a wrench for a living.

    They say things like:

    • I design concrete retaining walls
    • I simulate the transients on a transmission line
    • I design heat exchangers
    • I model the absorbency of diapers
    • I design subsea pipelines
    • I need to optimize the trajectory of a space shuttle
    • I work for a power generation company doing load flow analysis
    • I model how a robot arm needs to move

    Some of these applications are mathematically simple (but are based on scientific principles, such as the conservation of heat, mass and momentum). The equations consist of basic arithmetic operations, trig and log functions, sprinkled with the occasional numeric integration.

    Sometimes, the equations are already formalized in design guides, published by organizations like the IEEE, ASME or ISO. Given the specific physical context, engineers just need to implement the calculations in the right order (this is especially true for Civil and Structural engineering). These applications require you to think at an engineering level.

    These are what we call design calculations, done by design engineers.

    On the other end of the spectrum, some of these applications are mathematically complex. You might need to derive equations, manipulate PDEs, work with quaternions or transformation matrices, or do some programming. These applications require you to think at a mathematical level.

    Let’s call the engineers doing this type of work research engineers. Research engineers are often more closely aligned with mathematicians than design engineers.

    So we have design engineers and research engineers (and of course we have engineers with feet in both camps, to a varying degree).

    Research engineers and design engineers do different mathematical things, and have different mathematical needs. Both groups use Maple, but one size doesn’t always fit well. Either the toe pinches a little, or the shirt is a mite too baggy.

    This is where Maple Flow enters stage right.

    Maple Flow is a new tool that we’ve built (and are continuing to expand and improve) with the needs of design engineers in mind.

    • The worksheet lets you put math anywhere – just point, click and type
    • The evaluation model is forward-in-space (unlike Maple’s forward in time evaluation model). This means the execution order is explicitly given by the position of the math on the canvas.
    • The worksheet updates automatically, so results are never stale
    • We’ve made several simplifications to massage away some of the complexity of the Maple programming language.
    • You can use nearly all of tools in the Maple programming language.

    Here’s how we see people using Maple Flow. They

    • Enter a few major equations somewhere, followed by some parameters scattered around
    • Make the equations “see” the parameters by moving the parameters above the equations
    • Insert any parameters or equations you’ve forgotten, and move them into position, shifting the existing content out of the way to make room
    • Add text, and perhaps an image or plot
    • Finally, align math and format text for a presentable document

    I’ve been using Maple Flow for a while now. I like the fact that the nature of Maple Flow means that you don’t have to start with a grand plan, with every computational detail planned out in advance. You’re encouraged to make things up as you go along, and gradually sculpt your calculations into shape.

    Basically, Maple Flow doesn’t issue stiff penalties for making mistakes. You fix them, and then move on.

    I also like that Maple Flow makes you feel like you’re “touching” your equations, shifting things about easily with either the mouse or the keyboard. There’s a certain tactility and immediacy to Maple Flow that gives me a micro dose of dopamine every time I use it.

    Maple Flow’s freeform interface lets you experiment with space, alignment and layout, drawing attention to different groups of equations.

    For example, you can design calculation documents that look like this.

    You can use nearly all of the Maple programming language in Flow. Here’s a command from the plots package.

    Here’s fsolve in action.

    The Maple Flow website has more information, including a demo video.

    As ever, your feedback is gratefully received.

    Yesterday, user @lcz , while responding as a third party to one of my Answers regarding GraphTheory, asked about breadth-first search. So, I decided to write a more-interesting example of it than the relatively simple example that was used in that Answer. I think that this is general enough to be worthy of a Post.

    This application generates all maximal paths in a graph that begin with a given vertex. (I'm calling a path maximal if it cannot be extended and remain a path.) This code requires Maple 2019 or later and 1D input. This works for both directed and undirected graphs. Weights, if present. are ignored.

    AllMaximalPaths:= proc(G::GRAPHLN, v)
        "All maximal paths of G starting at v by breadth-first search"
    option `Author: Carl Love <> 2021-Mar-17`;
    uses GT= GraphTheory;
        P:= [rtable([v])], R:= rtable(1..0),
        VL:= GT:-Vertices(G), V:= table(VL=~ [$1..nops(VL)]),
        Departures:= {op}~(GT:-Departures(G))
        while nops(P) <> 0 do
            P:= [
                for local p in P do
                    local New:= Departures[V[p[-1]]] minus {seq}(p);
                    if New={} then R,= [seq](p); next fi;                
                        for local u in New do 
                            local p1:= rtable(p); p1,= u
    end proc
    #large example:
    GT:= GraphTheory:
    K9:= GT:-CompleteGraph(9):
    Pa:= CodeTools:-Usage(AllMaximalPaths(K9,1)):
    memory used=212.56MiB, alloc change=32.00MiB, 
    cpu time=937.00ms, real time=804.00ms, gc time=312.50ms
    #fun example:
    P:= GT:-SpecialGraphs:-PetersenGraph():
    Pa:= CodeTools:-Usage(AllMaximalPaths(P,1)):
    memory used=0.52MiB, alloc change=0 bytes, 
    cpu time=0ns, real time=3.00ms, gc time=0ns
    Pa[..9]; #sample paths
        {[1, 2, 3, 4, 10, 9, 8, 5], [1, 2, 3, 7, 8, 9, 10, 6], 
          [1, 2, 9, 8, 7, 3, 4, 5], [1, 2, 9, 10, 4, 3, 7, 6], 
          [1, 5, 4, 3, 7, 8, 9, 2], [1, 5, 4, 10, 9, 8, 7, 6], 
          [1, 5, 8, 7, 3, 4, 10, 6], [1, 5, 8, 9, 10, 4, 3, 2], 
          [1, 6, 7, 3, 4, 10, 9, 2]}

    Notes on the procedure:

    The two dynamic data structures are

    • P: a list of vectors of vertices. Each vector contains a path which we'll attempt to extend.
    • R: a vector of lists of vertices. Each list is a maximal path to be returned.

    The static data structures are

    • V: a table mapping vertices (which may be named) to their index numbers.
    • Departures: a list of sets of vertices whose kth set is the possible next vertices from vertex number k.

    On each iteration of the outer loop, P is completely reconstructed because each of its entries, a path p, is either determined to be maximal or it's extended. The set New is the vertices that can be appended to the (connected to vertex p[-1]). If New is empty, then p is maximal, and it gets moved to R

    The following code constructs an array plot of all the maximal paths in the Petersen graph. I can't post the array plot, but you can see it in the attached worksheet:

    #Do an array plot of each path embedded in the graph:
    n:= nops(Pa):
    c:= 9: 
        (PA:= rtable(
            (1..ceil(n/c), 1..c),
                if (local k:= (i-1)*ceil(n/c) + j) > n then 
                    plot(axes= none)
                        GT:-HighlightTrail(P, Pa[k], inplace= false), 
                        stylesheet= "legacy", title= typeset(Pa[k])
        titlefont= [Times, Bold, 12]
    #And recast that as an animation so that I can post it:
        [seq](`$`~(plots:-display~(PA), 5)),


    I am a high school Teacher in Denmark, who have been using Maple since version 12, more than 12 years ago. I suggested it for my school back then and our math faculty finally decided to purchase a school license. We are still there. We have watched Maple improve in a lot of areas (function definitions, context panels, graphically etc., etc ). Often small changes makes a big difference! We have been deligted. We we are mostly interested in improvements in GUI and lower level math, and in animations and quizzes. I have also been enrolled as a beta tester for several years yet. 

    One of the areas, which is particually important is print and export to pdf, because Danish students have to turn in their papers/solutions at exams in pdf format! I guess the Scandinavian countries are ahead in this department. They may quite possible be behind in other areas however, but this is how it is. 

    Now my point: Maplesoft is lacking terrible behind when regarding screen look in comparison with print/export to pdf. 

    I am very frustrated, because I have been pinpointing this problem in several versions of Maple, both on Mapleprimes and in the beta groups. Some time you have corrected it, but it has always been bouncing back again and again! I have come to the opinion that you are not taking it seriously? Why?

    Students may loose grades because of missing documentations (marking on graphs etc.). 

    I will be reporting yet another instance of this same problem. When will it stop?



    Wirtinger Derivatives in Maple 2021

    Generally speaking, there are two contexts for differentiating complex functions with respect to complex variables. In the first context, called the classical complex analysis, the derivatives of the complex components ( abs , argument , conjugate , Im , Re , signum ) with respect to complex variables do not exist (do not satisfy the Cauchy-Riemann conditions), with the exception of when they are holomorphic functions. All computer algebra systems implement the complex components in this context, and computationally represent all of abs(z), argument(z), conjugate(z), Im(z), Re(z), signum(z) as functions of z . Then, viewed as functions of z, none of them are analytic, so differentiability becomes an issue.


    In the second context, first introduced by Poincare (also called Wirtinger calculus), in brief z and its conjugate conjugate(z) are taken as independent variables, and all the six derivatives of the complex components become computable, also with respect to conjugate(z). Technically speaking, Wirtinger calculus permits extending complex differentiation to non-holomorphic functions provided that they are ℝ-differentiable (i.e. differentiable functions of real and imaginary parts, taking f(z) = f(x, y) as a mapping "`&Ropf;`^(2)->`&Ropf;`^()").


    In simpler terms, this subject is relevant because, in mathematical-physics formulations using paper and pencil, we frequently use Wirtinger calculus automatically. We take z and its conjugate conjugate(z) as independent variables, with that d*conjugate(z)*(1/(d*z)) = 0, d*z*(1/(d*conjugate(z))) = 0, and we compute with the operators "(&PartialD;)/(&PartialD; z)", "(&PartialD;)/(&PartialD; (z))" as partial differential operators that behave as ordinary derivatives. With that, all of abs(z), argument(z), conjugate(z), Im(z), Re(z), signum(z), become differentiable, since they are all expressible as functions of z and conjugate(z).



    Wirtinger derivatives