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
  • 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.

    These all reduce the effort to build and update models and add more detail to the simulations. The result: faster to innovate, shorter testing cycles, and more value from every simulation.

    You can read more about the MapleSim new features.

    Announcing the new Research Partnership Program for MapleSim

    We are pleased to announce a new collaboration between Maplesoft and the research teams that are actively advancing converting and web manufacturing processes.
    The MapleSim for Web Converting Systems - Research Partnership Program:

    • To support research communities across the web handling industry by providing licenses for MapleSim for Web Converting Systems at NO COST.

    Our goal is to equip researchers with the same advanced modeling and simulation tools used in industry, helping them explore new concepts, test ideas, and drive meaningful discoveries.

    Focus areas for research include:

    • manufacturing foils, plastic films, non-wovens, and other thin web materials.
    • any specialty process for handling or producing medical equipment, semi-conductors, or EV batteries.

    More details of the program and the application process are available on this page.
     

    How Simulation Gives You Operational Insights

    We have a new web series of articles “R2R Operational Insights” that showcase the ways MapleSim models deliver deeper insights, greater efficiency, and better product quality. These modeling use case articles are sprinkled with customer stories from the world of packaging, EV battery manufacturing, and printing.

    You can browse the R2R Operational Insight articles here.

     

    Conclusion: Try MapleSim for Yourself

    Together, these updates make it easier than ever to simulate, innovate, and learn in web-based manufacturing and design.
    -->Start your Free Trial!

     

    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.

    Maplesoft Open Maple Java Programming Interface : Bug Report 1

    Subject

    -------------------------------------------------------------
    FATAL ERROR in native method: Using JNIEnv in non-Java thread
    -------------------------------------------------------------

    Unexpected and apparently inconsistent threading behaviour.

    Perhaps due to default callback semantics ?

    Hello Maplesoft Support team,

    Environment

    * Maple: Maple 2024.2 (build used in our tests) Build ID #18723373
    * OS: macOS (Apple Silicon / arm64) Sequoia 15.7.1 32 GB
    * uname output from the failing machine: Darwin Mac-Mini.local 24.6.0 Darwin Kernel Version 24.6.0: Mon Aug 11 21:16:30 PDT 2025; root:xnu-11417.140.69.701.11~1/RELEASE_ARM64_T8132 arm64  
    * JDK: openjdk 21.0.8 2025-07-15 LTS (Temurin 21.0.8+9)  
     
    * Maple Java jars in use:
        * /Library/Frameworks/Maple.framework/Versions/2024/java/jopenmaple.jar
        * /Library/Frameworks/Maple.framework/Versions/2024/java/externalcall.jar
    * Native libraries loaded from:
        * /Library/Frameworks/Maple.framework/Versions/2024/bin.APPLE_ARM64_MACOS

    Exact java command used to run OpenMapleBug1:

    java -Xcheck:jni --enable-native-access=ALL-UNNAMED -Xrs \  
      -cp .:/Library/Frameworks/Maple.framework/Versions/2024/java/jopenmaple.jar:/Library/Frameworks/Maple.framework/Versions/2024/java/externalcall.jar \  
      -Djava.library.path=/Library/Frameworks/Maple.framework/Versions/2024/bin.APPLE_ARM64_MACOS \  
      OpenMapleBug1  

    Minimal Java reproducer:

    import com.maplesoft.openmaple.*;
    import com.maplesoft.externalcall.MapleException;
    import java.util.*;

    public class OpenMapleBug1
    {
        public static void main(String[] args) throws Exception
        {
            String[] mapleArgs = { "java" };

            try
            {
                Engine engine = new Engine(mapleArgs, new EngineCallBacksDefault(), null, null);
                String expr1 = "diff( tan( x )/exp( x ), x );";
                String expr2 = "u_general := sum(B[n] * sin(n*Pi*x/L) * exp(-alpha*(n*Pi/L)^2*t), n=1..infinity);";
                System.out.println("Evaluating: " + expr1);
                engine.evaluate(expr1);
                System.out.println("Evaluating: " + expr2);
                engine.evaluate(expr2);
                System.out.println("Success");
            }
            catch (MapleException e)
            {
                System.out.println("Error: " + e);
                e.printStackTrace();
            }
        }
    }

    Observed Behaviour

    Two calls are made to OpenMaple. The first succeeds:

    Evaluating: diff( tan( x )/exp( x ), x );
    (1+tan(x)^2)/exp(x)-tan(x)/exp(x)

    The second fails (cf. OpenMapleBug2 (which is actually my main line of investigation); also submitted).

    Evaluating: u_general := sum(B[n] * sin(n*Pi*x/L) * exp(-alpha*(n*Pi/L)^2*t), n=1..infinity);

    FATAL ERROR in native method: Using JNIEnv in non-Java thread
    zsh: abort      java -Xcheck:jni --enable-native-access=ALL-UNNAMED -Xrs -cp    OpenMapleBug1

    =========================================
    Suggested actions for Maplesoft engineers
    =========================================

    * Reproduce on macOS Apple Silicon using the provided reproducer and command line.
    * Check whether this regression is present on other platforms (x86 mac, Linux) and JDK versions.
    * Provide a fix for Maple 2024.2 (and Maple 2025.x if applicable).

    Thank-you.

     

    Maplesoft Open Maple Java Programming Interface : Bug Report 2

    Subject

    Native crash (SIGSEGV) in libmaple.dylib when evaluating symbolic sum with indexed coefficients (B[n]) — macOS Apple Silicon — Maple 2024.2

    Hello Maplesoft Support team,

    I’m reporting a native crash (SIGSEGV) inside libmaple.dylib that occurs when evaluating a symbolic sum containing indexed symbolic coefficients (for example B[n]) via the Maple Java Engine API (jopenmaple). The crash aborts the JVM and produces hs_err_pid34602.log. This is available: email me to receive it.. Rewriting the indexed symbol as a function (for example B(n)) avoids the crash, which suggests a native bug in Maple’s handling of indexed symbolic objects during summation/conversion/evaluation.

    Please find environment, exact commands, a minimal reproducer, hs_err_pid34602.log (email), and suggested tests and actions below.

    Environment

    * Maple: Maple 2024.2 (build used in our tests) Build ID #18723373

    * OS: macOS (Apple Silicon / arm64) Sequoia 15.7.1 32 GB
        * uname output from the failing machine: Darwin Mac-Mini.local 24.6.0 Darwin Kernel Version 24.6.0: Mon Aug 11 21:16:30 PDT 2025; root:xnu-11417.140.69.701.11~1/RELEASE_ARM64_T8132 arm64  

    JDK: openjdk 21.0.8 2025-07-15 LTS
    OpenJDK Runtime Environment Temurin-21.0.8+9 (build 21.0.8+9-LTS)
    OpenJDK 64-Bit Server VM Temurin-21.0.8+9 (build 21.0.8+9-LTS, mixed mode, sharing)

    Maple Java jars in use:
        * /Library/Frameworks/Maple.framework/Versions/2024/java/jopenmaple.jar
        * /Library/Frameworks/Maple.framework/Versions/2024/java/externalcall.jar

    Native libraries loaded from:
        * /Library/Frameworks/Maple.framework/Versions/2024/bin.APPLE_ARM64_MACOS

    Exact java command used to run MinimalSumTest2:

    java -Xcheck:jni --enable-native-access=ALL-UNNAMED -Xrs \  
      -cp .:/Library/Frameworks/Maple.framework/Versions/2024/java/jopenmaple.jar:/Library/Frameworks/Maple.framework/Versions/2024/java/externalcall.jar \  

      -Djava.library.path=/Library/Frameworks/Maple.framework/Versions/2024/bin.APPLE_ARM64_MACOS \  
      MinimalSumTest2  

    Note: Adding -Xss100M did not make any apparent difference.


    Minimal Java reproducer (attach as MinimalSumTest2.java):

    // MinimalSumTest2.java

    public class MinimalSumTest2
    {
        public static void main(String[] args)
        {
            String[] mapleArgs = new String[] { "java" }; // some versions require this
            com.maplesoft.openmaple.Engine engine = null;
            try
            {
                System.out.println("Creating Engine...");
                engine = new com.maplesoft.openmaple.Engine(
                    mapleArgs,
                    new com.maplesoft.openmaple.EngineCallBacksDefault(),
                    null,
                    null
                );

                // assign with ":" to suppress printing (should avoid large marshalled result)
                String assignSuppressed = "u_test := sum(B[n]*sin(n*Pi*x/L)*exp(-alpha*(n*Pi/L)^2*t), n=1..100):";
                System.out.println("Evaluating (suppressed): " + assignSuppressed);
                engine.evaluate(assignSuppressed);
                System.out.println("Assigned (suppressed) OK");

                System.out.println("Done.");
            } catch (Throwable t)
            {
                System.err.println("Unexpected throwable (may be native crash):");
                t.printStackTrace();
                // If a SIGSEGV occurs, JVM may abort before this runs; look for hs_err_pid*.log
            } finally
            {
                // no stop() method available
            }
        }

    }

    Observed Behavior

    * JVM aborts with SIGSEGV in native code (libmaple.dylib). The hs_err log shows frames in:
        * libmaple.dylib : errorJmp(_ThreadLocalData*) / extIsNumeric
        * libjopenmaple.jnilib : newAlgebraic / Java_com_maplesoft_openmaple_Engine_evaluate

    * Using B(n) (function form) instead of B[n] or substituting numeric coefficients avoids the crash.

    Attached crash evidence

    * hs_err_pid34602.log is available: email me to receive it.
    * Please use the full hs_err file for diagnostics; it contains native frames, thread state and loaded libraries.

    Suggested quick tests to run (please include pass/fail for each):

    1. Replace indexed form with function form:
        * B := n -> b^n: u := sum(B(n)*sin(...), n=1..100): — does this crash?
    2. Reduce N (small upper bound):
        * sum(B[n]*sin(...), n=1..10): — crash or not?
    3. Use a table in place of indexed name: Btab := table():  
    4. for k from 1 to 100 do Btab[k] := b || k od:  
    5. sum(Btab[n]*sin(...), n=1..100):  
    6. Pre-substitute a simple expression for B[n] before summing:
        * sum(subs(B[n]=1/n, B[n]*sin(...)), n=1..100):
    7. Try same reproducer on a non-Apple-Silicon mac or Linux (if available) and with JDK 17.

    Suggested cause (based on hs_err frames):

    * Crash appears to occur in native routines that check numeric-ness / build algebraic objects (functions such as extIsNumeric and newAlgebraic). This indicates a bug in Maple’s native handling/conversion of indexed symbolic objects in sum/convert/evaluate code paths.

    Temporary workarounds
    * Use function form: B := n -> ... and B(n) in sums rather than B[n].
    * Substitute definitions for B[n] before summation (client-side or via subs) so that the sum does not carry an indexed symbolic name into the conversion step.
    * Build sums client-side (Java/Clojure) or use explicit truncated numeric sums when possible.

    Files to attach (recommended)
    * hs_err_pid*.log (full file)
    * MinimalSumTest.java (the Java reproducer above)
    * README_cmd.txt (contains exact javac and java commands used)
    * java_version.txt (output of java --version)
    * maplesoft_jars_list.txt (paths to jopenmaple.jar and externalcall.jar used)

    =========================================

    Suggested actions for Maplesoft engineers
    =========================================

    * Email me to receive the error log file produced for the crash.
    * Reproduce on macOS Apple Silicon using the provided reproducer and command line.
    * Inspect handling of indexed name objects inside summation/conversion code paths — particularly code interacting with extIsNumeric, newAlgebraic, and conversion routines invoked by Engine.evaluate.
    * Check whether this regression is present on other platforms (x86 mac, Linux) and JDK versions.
    * Provide either a patch that prevents this conversion path from dereferencing invalid memory, or return a safe Maple-level error for unsupported symbolic forms.

    Thank-you.


     

    I was honored to give a talk about the MRB constant at the INTERNATIONAL 10th USBILIM APPLIED SCIENCES.

    If you're unfamiliar with the MRB constant, this is a solid introduction to it.

    (28) INTRODUCING THE MRB CONSTANT: CONVERGENCE, GEOMETRY, AND OPEN PROBLEMS

    [Edit: a general procedure based on these ideas is given below.]

    Maple's isolve can solve some but not all of the quadratic equations in two variables describing the conic sections. Here I show that by transforming the equations, Maple can then solve these missing cases.

    restart

    with(plots)

    I was recently surprised that isolve cannot solve the following simple Diophantine equation

    isolve(2*x^2+4*x*y+y^2 = 7)

    which has the obvious (to a human) solution {x = 1, y = 1}. This led me to think about the case of conic sections, which have the following general equation (= 0 implied), where I assume a, () .. (), f are integers.

    P := a*x^2+b*x*y+c*y^2+d*x+e*y+f

    a*x^2+b*x*y+c*y^2+d*x+e*y+f

    The above equation has discriminant -4*a*c+b^2 positive, indicating that is is a hyperbola.

    h_params := {a = 2, b = 4, c = 1, d = 0, e = 0, f = -7}; P__h := eval(P, h_params); disc := -4*a*c+b^2; eval(disc, h_params); plot__h := implicitplot(P__h, x = -10 .. 10, y = -10 .. 10, colour = red)

    {a = 2, b = 4, c = 1, d = 0, e = 0, f = -7}

    2*x^2+4*x*y+y^2-7

    -4*a*c+b^2

    8

    Here's a parabola case (discriminant = 0) that isolve also has trouble with

    p_params := {a = 2, b = 4, c = 2, d = 1, e = 2, f = 7}; eval(disc, p_params); P__p := eval(P, p_params); {isolve(P__p)}; plot__h := implicitplot(P__p, x = -10 .. 10, y = -10 .. 10, colour = red)

    {a = 2, b = 4, c = 2, d = 1, e = 2, f = 7}

    0

    2*x^2+4*x*y+2*y^2+x+2*y+7

    {}

    But this has at least one solution

    eval(P__p, {x = 7, y = -7})

    0

    Maple seems to do better in the elliptic case (discriminant negative) and finds two solutions. Examination of the plot suggests there are no other solutions.

    e_params := {a = 2, b = 4, c = 3, d = 1, e = 2, f = -7}; eval(disc, e_params); P__e := eval(P, e_params); {isolve(P__e)}; plot__e := implicitplot(P__e, x = -10 .. 10, y = -10 .. 10, colour = red)

    {a = 2, b = 4, c = 3, d = 1, e = 2, f = -7}

    -8

    2*x^2+4*x*y+3*y^2+x+2*y-7

    {{x = -3, y = 2}, {x = 2, y = -3}}

    I show that transformation of the general equation to the form -D*Y^2+X^2 = m, where D is the discriminant, allows Maple to solve the hyperbolic case, as well as the elliptic case it already knows how to solve; another transformation works for the parabolic case. Maple appears to be able to solve all (solvable) cases of the transformed equations, though this is not clear from the help page. The transformation is discussed in Bogdan Grechuk, Polynomial Diophantine Equations: A Systematic Approach, Springer, 2024, Sec. 3.1.7. doi: 10.1007/978-3-031-62949-5

     

    A complete classification of the conics, including degenerate cases, is given in https://en.wikipedia.org/wiki/Matrix_representation_of_conic_sections. If the determinant, delta, of the following matrix is zero, we have a degenerate case.

    A__Q := Matrix(3, 3, [a, (1/2)*b, (1/2)*d, (1/2)*b, c, (1/2)*e, (1/2)*d, (1/2)*e, f]); delta := LinearAlgebra:-Determinant(A__Q)

    Matrix(%id = 36893489963432522084)

    a*c*f-(1/4)*a*e^2-(1/4)*b^2*f+(1/4)*b*d*e-(1/4)*c*d^2

    The case of a = b and b = c and c = 0 is just the linear case, which Maple can solve, and is one case where D = delta and delta = 0. Other degenerate parabola cases are two coincident lines or two parallel lines. Degenerate hyperbolas are two intersecting lines, and degenerate ellipses are a single point. Maple can solve all these cases, e.g.,NULL

    expand((2*x+3*y+1)*(2*x+3*y)); {isolve(%)}; expand((2*x+3*y)*(2*x+3*y)); {isolve(%)}; expand((x-2)*(y-3)); {isolve(%)}; x^2+y^2 = 0; {isolve(%)}

    4*x^2+12*x*y+9*y^2+2*x+3*y

    {{x = -3*_Z1, y = 2*_Z1}, {x = -2-3*_Z1, y = 1+2*_Z1}}

    4*x^2+12*x*y+9*y^2

    {{x = -3*_Z1, y = 2*_Z1}}

    x*y-3*x-2*y+6

    {{x = _Z1, y = 3}}

    x^2+y^2 = 0

    {{x = 0, y = 0}}

    (The intersecting lines case above only finds one of the lines.) The transformation will consider only the case where at least one of a or c is non-zero. This misses hyperbolas with a = c and c = 0; Maple seems to handle these bilinear equations, e.g.,

    bl_params := {a = 0, b = 2, c = 0, d = 1, e = 1, f = 2}; P__bl := eval(P, bl_params); {isolve(P__bl)}

    {a = 0, b = 2, c = 0, d = 1, e = 1, f = 2}

    2*x*y+x+y+2

    {{x = -2, y = 0}, {x = -1, y = 1}, {x = 0, y = -2}, {x = 1, y = -1}}

    Transformation for non-zero discriminant
    At least one of a or c must be non-zero; if necessary exchange x and y to ensure a is non-zero.

    We multiply P by -4*a*(-4*a*c+b^2) and change to new variables X and Y.

    itr := {X = (-4*a*c+b^2)*y+b*d-2*a*e, Y = 2*a*x+b*y+d}; tr := solve(itr, {x, y})

    {X = (-4*a*c+b^2)*y+b*d-2*a*e, Y = 2*a*x+b*y+d}

    {x = (1/2)*(4*Y*a*c-Y*b^2+2*a*b*e-4*a*c*d+X*b)/((4*a*c-b^2)*a), y = -(2*a*e-b*d+X)/(4*a*c-b^2)}

    The transformed equation has the form -D*Y^2+X^2-m = 0 or -D*Y^2+X^2 = m, where D is the discriminant.

    Q := collect(normal(eval(-4*P*a*(-4*a*c+b^2), tr)), {X, Y}); m := -coeff(coeff(Q, X, 0), Y, 0)

    X^2+(4*a*c-b^2)*Y^2+16*a^2*c*f-4*a^2*e^2-4*a*b^2*f+4*a*b*d*e-4*a*c*d^2

    -16*a^2*c*f+4*a^2*e^2+4*a*b^2*f-4*a*b*d*e+4*a*c*d^2

    For positive discriminant D, this is a general Pell's equation, -D*Y^2+X^2 = m, which Maple knows how to solve. (The definition of Pell's equation requires that D is not a square, but Maple can also solve the simpler case where D is a square.) For the hyperbola above, we have an infinite number of solutions, parameterized by an arbitrary integer _Z1.

    Q__h := eval(Q, h_params); solXY__h := {isolve(Q__h)}

    X^2-8*Y^2+448

    {{X = -12*(1+2^(1/2))^(1+2*_Z1)-12*(1-2^(1/2))^(1+2*_Z1)-4*2^(1/2)*((1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1)), Y = -3*2^(1/2)*((1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1))-2*(1+2^(1/2))^(1+2*_Z1)-2*(1-2^(1/2))^(1+2*_Z1)}, {X = -12*(1+2^(1/2))^(1+2*_Z1)-12*(1-2^(1/2))^(1+2*_Z1)-4*2^(1/2)*((1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1)), Y = 3*2^(1/2)*((1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1))+2*(1+2^(1/2))^(1+2*_Z1)+2*(1-2^(1/2))^(1+2*_Z1)}, {X = -12*(1+2^(1/2))^(1+2*_Z1)-12*(1-2^(1/2))^(1+2*_Z1)+4*2^(1/2)*((1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1)), Y = -3*2^(1/2)*((1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1))+2*(1+2^(1/2))^(1+2*_Z1)+2*(1-2^(1/2))^(1+2*_Z1)}, {X = -12*(1+2^(1/2))^(1+2*_Z1)-12*(1-2^(1/2))^(1+2*_Z1)+4*2^(1/2)*((1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1)), Y = 3*2^(1/2)*((1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1))-2*(1+2^(1/2))^(1+2*_Z1)-2*(1-2^(1/2))^(1+2*_Z1)}, {X = 12*(1+2^(1/2))^(1+2*_Z1)+12*(1-2^(1/2))^(1+2*_Z1)-4*2^(1/2)*((1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1)), Y = -3*2^(1/2)*((1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1))+2*(1+2^(1/2))^(1+2*_Z1)+2*(1-2^(1/2))^(1+2*_Z1)}, {X = 12*(1+2^(1/2))^(1+2*_Z1)+12*(1-2^(1/2))^(1+2*_Z1)-4*2^(1/2)*((1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1)), Y = 3*2^(1/2)*((1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1))-2*(1+2^(1/2))^(1+2*_Z1)-2*(1-2^(1/2))^(1+2*_Z1)}, {X = 12*(1+2^(1/2))^(1+2*_Z1)+12*(1-2^(1/2))^(1+2*_Z1)+4*2^(1/2)*((1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1)), Y = -3*2^(1/2)*((1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1))-2*(1+2^(1/2))^(1+2*_Z1)-2*(1-2^(1/2))^(1+2*_Z1)}, {X = 12*(1+2^(1/2))^(1+2*_Z1)+12*(1-2^(1/2))^(1+2*_Z1)+4*2^(1/2)*((1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1)), Y = 3*2^(1/2)*((1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1))+2*(1+2^(1/2))^(1+2*_Z1)+2*(1-2^(1/2))^(1+2*_Z1)}}

    Transforming back to the original coordinates

    sol__h := {seq(eval(eval(tr, h_params), solXY), `in`(solXY, solXY__h))}

    {{x = -2*(1+2^(1/2))^(1+2*_Z1)-2*(1-2^(1/2))^(1+2*_Z1)-(5/4)*2^(1/2)*((1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1)), y = (3/2)*(1+2^(1/2))^(1+2*_Z1)+(3/2)*(1-2^(1/2))^(1+2*_Z1)+(1/2)*2^(1/2)*((1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1))}, {x = -2*(1+2^(1/2))^(1+2*_Z1)-2*(1-2^(1/2))^(1+2*_Z1)+(5/4)*2^(1/2)*((1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1)), y = (3/2)*(1+2^(1/2))^(1+2*_Z1)+(3/2)*(1-2^(1/2))^(1+2*_Z1)-(1/2)*2^(1/2)*((1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1))}, {x = -(1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1)-(1/4)*2^(1/2)*((1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1)), y = (3/2)*(1+2^(1/2))^(1+2*_Z1)+(3/2)*(1-2^(1/2))^(1+2*_Z1)-(1/2)*2^(1/2)*((1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1))}, {x = -(1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1)+(1/4)*2^(1/2)*((1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1)), y = (3/2)*(1+2^(1/2))^(1+2*_Z1)+(3/2)*(1-2^(1/2))^(1+2*_Z1)+(1/2)*2^(1/2)*((1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1))}, {x = (1+2^(1/2))^(1+2*_Z1)+(1-2^(1/2))^(1+2*_Z1)-(1/4)*2^(1/2)*((1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1)), y = -(3/2)*(1+2^(1/2))^(1+2*_Z1)-(3/2)*(1-2^(1/2))^(1+2*_Z1)-(1/2)*2^(1/2)*((1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1))}, {x = (1+2^(1/2))^(1+2*_Z1)+(1-2^(1/2))^(1+2*_Z1)+(1/4)*2^(1/2)*((1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1)), y = -(3/2)*(1+2^(1/2))^(1+2*_Z1)-(3/2)*(1-2^(1/2))^(1+2*_Z1)+(1/2)*2^(1/2)*((1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1))}, {x = 2*(1+2^(1/2))^(1+2*_Z1)+2*(1-2^(1/2))^(1+2*_Z1)-(5/4)*2^(1/2)*((1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1)), y = -(3/2)*(1+2^(1/2))^(1+2*_Z1)-(3/2)*(1-2^(1/2))^(1+2*_Z1)+(1/2)*2^(1/2)*((1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1))}, {x = 2*(1+2^(1/2))^(1+2*_Z1)+2*(1-2^(1/2))^(1+2*_Z1)+(5/4)*2^(1/2)*((1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1)), y = -(3/2)*(1+2^(1/2))^(1+2*_Z1)-(3/2)*(1-2^(1/2))^(1+2*_Z1)-(1/2)*2^(1/2)*((1+2^(1/2))^(1+2*_Z1)-(1-2^(1/2))^(1+2*_Z1))}}

    Evaluate for some _Z1 values, say _Z1=0 and _Z1=5.
    It is evident from tr above that integer solutions in X, Y may transform to non-integer solutions in x, y but that doesn't occur for these two cases

    sol__h0 := evala(eval(sol__h, _Z1 = 0)); sol__h5 := evala(eval(sol__h, _Z1 = 5))

    {{x = -9, y = 5}, {x = -3, y = 1}, {x = -1, y = -1}, {x = -1, y = 5}, {x = 1, y = -5}, {x = 1, y = 1}, {x = 3, y = -1}, {x = 9, y = -5}}

    {{x = -61181, y = 35839}, {x = -21979, y = 12875}, {x = -10497, y = 35839}, {x = -3771, y = 12875}, {x = 3771, y = -12875}, {x = 10497, y = -35839}, {x = 21979, y = -12875}, {x = 61181, y = -35839}}

    Check they are solutions to P__h

    map2(eval, P__h, `union`(sol__h0, sol__h5))

    {0}

    For negative discriminant and negative m, the equation -D*Y^2+X^2 = m has no solutions. In the classification scheme for the conics, the "imaginary ellipse" case (no real solutions) occurs when (a+c)*delta > 0. For negative discriminant, we must have a and c the same sign, and this is the case of negative m.

    factor(expand((16*(a+c))*delta)); factor(-m)

    4*(a+c)*(4*a*c*f-a*e^2-b^2*f+b*d*e-c*d^2)

    4*a*(4*a*c*f-a*e^2-b^2*f+b*d*e-c*d^2)

    . In this case Maple returns NULL for both the untransformed and transformed case, which can mean no solutions or just that isolve couldn't find any.

    ie_params := {a = 3, b = 0, c = 5, d = 0, e = 0, f = 8}; P__ie := eval(P, ie_params); {isolve(P__ie)}; Q__ie := eval(Q, ie_params); {isolve(Q__ie)}

    {a = 3, b = 0, c = 5, d = 0, e = 0, f = 8}

    3*x^2+5*y^2+8

    {}

    X^2+60*Y^2+5760

    {}

    For negative discriminant and positive m or (a+c)*delta < 0, the ellipse is real, and there are a finite number of solutions. Maple solves the untransformed and transformed equations.
    Here we need to filter out non-integer solutions

    P__e; {isolve(P__e)}; Q__e := eval(Q, e_params); solXY__e := {isolve(Q__e)}; {seq(eval(eval(tr, e_params), solXY), `in`(solXY, solXY__e))}; sol__e := select(proc (q) options operator, arrow; eval(x::integer, q) and eval(y::integer, q) end proc, %)

    2*x^2+4*x*y+3*y^2+x+2*y-7

    {{x = -3, y = 2}, {x = 2, y = -3}}

    X^2+8*Y^2-472

    {{X = -20, Y = -3}, {X = -20, Y = 3}, {X = 20, Y = -3}, {X = 20, Y = 3}}

    {{x = -3, y = 2}, {x = 2, y = -3}, {x = -3/2, y = 2}, {x = 7/2, y = -3}}

    {{x = -3, y = 2}, {x = 2, y = -3}}

    Transformation for zero discriminant
    For the case of zero discriminant (parabola), we need a different transformation.

    itr0 := {X = 2*a*x+b*y+d, Y = y}; tr0 := solve(itr0, {x, y})

    {X = 2*a*x+b*y+d, Y = y}

    {x = (1/2)*(-Y*b+X-d)/a, y = Y}

    The transformed equation is of the form A*Y+X^2+B = 0

    Q0 := collect(normal(eval(4*a*P, tr0)), {X, Y})

    X^2+(4*a*c-b^2)*Y^2+(4*a*e-2*b*d)*Y+4*f*a-d^2

    We consider the parabolic example above, for which Maple finds no solutions without transformation.

    P__p; {isolve(P__p)}

    2*x^2+4*x*y+2*y^2+x+2*y+7

    {}

    For the transformed problem, Maple finds an infinite number of solutions

    Q__p := eval(Q0, p_params); solXY__p := {isolve(Q__p)}; sol__p := {seq(eval(eval(tr0, p_params), solXY), `in`(solXY, solXY__p))}

    X^2+8*Y+55

    {{X = 1+8*_Z1, Y = -8*_Z1^2-2*_Z1-7}, {X = 3+8*_Z1, Y = -8*_Z1^2-6*_Z1-8}, {X = 5+8*_Z1, Y = -8*_Z1^2-10*_Z1-10}, {X = 7+8*_Z1, Y = -8*_Z1^2-14*_Z1-13}}

    {{x = 17/2+8*_Z1+8*_Z1^2, y = -8*_Z1^2-6*_Z1-8}, {x = 29/2+16*_Z1+8*_Z1^2, y = -8*_Z1^2-14*_Z1-13}, {x = 8*_Z1^2+4*_Z1+7, y = -8*_Z1^2-2*_Z1-7}, {x = 8*_Z1^2+12*_Z1+11, y = -8*_Z1^2-10*_Z1-10}}

    Two of the general solutions will not give integer solutions, so could be filtered out, but it is easier to filter after choosing some specific _Z1 values.

    eval(sol__p, _Z1 = 0); sol__p0 := select(proc (q) options operator, arrow; eval(x::integer, q) and eval(y::integer, q) end proc, %); eval(sol__p, _Z1 = 5); sol__p5 := select(proc (q) options operator, arrow; eval(x::integer, q) and eval(y::integer, q) end proc, %)

    {{x = 7, y = -7}, {x = 11, y = -10}, {x = 17/2, y = -8}, {x = 29/2, y = -13}}

    {{x = 7, y = -7}, {x = 11, y = -10}}

    {{x = 227, y = -217}, {x = 271, y = -260}, {x = 497/2, y = -238}, {x = 589/2, y = -283}}

    {{x = 227, y = -217}, {x = 271, y = -260}}

    Check they are solutions to P__p

    map2(eval, P__p, `union`(sol__p0, sol__p5))

    {0}

    NULL

    Download DiophantineConics2.mw

    There is still time to register for Maple Conference 2025, which takes place November 5-7, 2025.

    The free registration includes access to three full days of presentations from Maplesoft product directors and developers, two distinguished keynote speakers, contributed talks by Maple users, and opportunities to network with fellow users, researchers, and Maplesoft staff.

    The final day of the conference will feature three in-depth workshops presented by the R&D team. You'll get hands-on experience with creating professional documents in Maple, learn how to solve various differential equations more effectively using Maple's numerical solvers, and explore the power of the Maple programming language while solving interesting puzzles.

    Access to the workshops is included with the free conference registration.

    We hope to see you there!

    Kaska Kowalska
    Contributed Program Co-chair

    It's possible to carve a hole through a unit cube, without splitting it into pieces, so that another unit cube can pass through that hole.  This is know as the Prince Rupert problem and was first analyzed by John Wallis, a contemporary of Isaac Newton.  Here's what the result looks like:

    If your computer can play audio, have a look at  Ruperts Cube with music!

    Here is the worksheet that produced the cube and the animation: ruperts-cube.mw

    Hi again everybody,

    Made some easy Maple code to find some special prime numbers.

    Namely, positive prmie numbers p 
    such that p, p+2, and p+6 are all prime numbers

    see prime_triples_p_p_and_2__p_and_6.mw

    prime_triples_p_p_and_2__p_and_6.pdf

    for your viewing pleasure

    Have a good day.

    Matthew

    The concept of an ode that has a function + integration variable as its solution is similar to that of a pde.

    A pde (with two variables as example here) that has a function as its solution + function integration variableIn ode, the shape of the solution curve is determined by the integration variable, and in a pde, the shape of the solution surface is determined by the function integration variable.

    "maple.ini in user"

    (1)

    NULL

     

     

    restart; with(plots); PlotPDEsurface := proc (Ct::procedure) local u_expr, FunsT; u_expr := rhs(pdsolve(diff(u(x, t), x) = 2*x+3*t)); FunsT := select(proc (u) options operator, arrow; type(u, 'function') and has(u, t) and not has(u, x) end proc, indets(u_expr, 'function')); if 0 < nops(FunsT) then u_expr := subs(FunsT[1] = Ct(t), u_expr) end if; return plot3d(u_expr, x = -2 .. 2, t = -2 .. 2, axes = boxed, grid = [60, 60], color = gold, transparency = .2, labels = ["x", "t", "u(x,t)"], title = "Solution surface u(x,t)") end proc

    "maple.ini in user"

    (1.1)

    PlotPDEsurface(proc (t) options operator, arrow; 0 end proc)

     

    PlotPDEsurface(proc (t) options operator, arrow; sin(t) end proc)

     

    restart; with(PDEtools); eq := diff(u(x, t), x) = 2*x+3*t; bc := u(0, t) = sin(t); sol := pdsolve({bc, eq}); Output; u(x, t) = 3*tx+x^2+sin(t)

    "maple.ini in user"

     

    u(x, t) = 3*t*x+x^2+sin(t)

     

    u(x, t) = 3*tx+x^2+sin(t)

    (1.2)

    restart; with(plots); u_expr := rhs(pdsolve(diff(u(x, t), x) = 2*x+3*t)); Cforms := [proc (t) options operator, arrow; 0 end proc, proc (t) options operator, arrow; t^2 end proc, proc (t) options operator, arrow; exp(-t^2) end proc, proc (t) options operator, arrow; sin(t)+3*cos(t) end proc]; Colors := [gold, blue, green, red]; Titles := ["C(t)=0", "C(t)=t^2", "C(t)=exp(-t^2)", "C(t)=sin(t)+3cos(t)"]; plots_list := []; for i to nops(Cforms) do expr_i := subs(f__1(t) = Cforms[i](t), u_expr); surf := plot3d(expr_i, x = -2 .. 2, t = -2 .. 2, color = Colors[i], transparency = .25, grid = [50, 50], axes = boxed, labels = ["x", "t", "u(x,t)"], title = Titles[i]); plots_list := [op(plots_list), surf] end do; display(plots_list, title = "Comparison of different C(t) forms", orientation = [120, 45])

    "maple.ini in user"

     

     
     

    NULL

    Download intergatie_functie_variabele_pde_onderzoek-engesle_versie.mw

    Imagine standing 365 metres above Toronto on the CN Tower’s EdgeWalk and throwing a baseball. Could you actually land it on third base at Rogers Centre, about 263 metres away?

    Sportsnet raised this question, and we decided to put it to the test in Maple Learn, check out this document to see the answer.


     

     

    Also take a look at the Sportsnet video on the problem, to see why the answer may not be obvious.

    In the Maple Learn document, you can adjust the initial speed and angle at which to throw the ball and then visualize its trajectory (without having to throw as hard as Addison Barger).

     

    I was surprised that even in the simplified projectile motion model, that neglects air resistance, AND assuming I could throw at 60mph (a questionable assumption to say the least) I wouldn’t be able to hit the base myself.

    I then used Maple to build a more realistic model that would account for air resistance. The equations below model the position of the ball, where y(0) = h0 is the initial height of 365m and v0 is the initial speed.

     

    local h0, m, d, rho, g:
    	h0 := 365:
    	m := 0.145:
    	d := 0.072:
    	rho := 1.225:
    	g := 9.81:
    
    	local eqns, ics:
    	eqns := diff(x(t),t) = u(t), 
    		    diff(y(t), t) = v(t), 
    		    diff(u(t), t)= -Pi/16 * d^2 * rho/m * sqrt(u(t)^2 + v(t)^2) * u(t), 
    		    diff(v(t), t)= - g - Pi/16 * d^2 * rho/m * sqrt(u(t)^2 + v(t)^2) * v(t):
    	ics := x(0) = 0, y(0)=h0, u(0) = v_initial*cos(theta_initial), v(0) = v_initial * sin(theta_initial):
    
    	local ans, xpos, ypos:
    	ans := dsolve([eqns, ics], numeric, output=listprocedure):
    	xpos := subs(ans, x(t));
    	ypos := subs(ans, y(t));

     

    In the Maple Learn document, you can visualize the difference between the models by comparing the trajectories. The trajectory from the simple model is shown in blue, and the trajectory after accounting for air resistance is modelled in red.

     

     

     

    Accounting for air resistance, I’m no longer convinced even Addison Barger could accomplish this challenge.

    Check out the Maple Learn document to try for yourself!

     

    The full program for Maple Conference 2025 is now available. 

    The agenda includes two full days of keynote speakers, presentations from Maplesoft product directors and developers, and contributed talks by Maple users all around the world. There will be opportunities to network with fellow users, researchers, and Maplesoft staff.

    The final day of the conference will include three in-depth workshops presented by the R&D team.
    The workshops will explore how to:

    • Create papers and reports in Maple
    • Solve various differential equations more effectively using Maple's numerical solvers
    • Solve Advent of Code challenges using Maple

    Access to the workshops is included with the free conference registration.

    We hope to see you there!

    Kaska Kowalska
    Program Co-chair

    This post presents a work I did to answer this recent question by @AHSAN.

    I believe that the two procedures I developed could be of interest to Mapleprimes members. Here they are in their most recent forms. However, I think they can still be improved and completed, and I am open to your suggestions for developing them further in this direction.

    BarGraph_2_Categories.mw
    Illustration


    BarGraph_3_Categories.mw
    Illustration

     

    In addition to the discussion on the desirability of having % available as a unit, I have a need to develop quantities that numerically have a unit of 1, such as per unit (pu), with pu:=1, and 1 pu = 100%. It is straightforward to define custom unit pu. However, the problem is that I end up getting numbers such as 16.60% pu (see below, should be one unit or the other, pu or %, not both):

     

    Curiously, if I click on the pu designation at variable X__dppv , Maple Flow removes the pu duplication and somehow knows that % is the intended unit:

    Percent_Ex.zip

    For a document that extensively uses per unit and % quantities, it is a lot of extra work to have to evaluate the decimal quantities first, then changing to % in the context menu, and then manually correcting all of the display issues with % and pu conflicts. Maple Flow does not seem to "remember" the result of the manual unit selection described above between file editing sessions. It also does not remember several other things related to formatting, container placement and spacing, column vectors not retaining a manually adjusted width, and section layout, but those are different issues. 

    I have noticed other examples of not remembering the correct units. For example, I have calculations where Maple Flow automatically returned a unit of 1/S in an initial calculation evaluation and I changed this in the context menu to ohms. Similar to the above discussion, upon re-opening the file, 1/S units appear. I cannot get that issue to consistently repeat, so it is not in the example Maple Flow document attached to this post, but the end result is the same - lots of re-formatting of the document from editing session to editing session.

    It would be nice if Maple Flow could recognize units that are numerically 1 so that they can be defined for display/documentation, added as necessary, but the result computed such that it is multiplication by 1 with no extra unit added. For example, enter 0.166 pu such that it evaluates to 0.166, with the option of then displaying as a percentage or re-displaying as per unit using the context menu. It would also be nice if Maple Flow could consistently remember the last retained unit used in an editing session as well as all document formatting. 

    Thanks

    1 2 3 4 5 6 7 Last Page 1 of 308