This system of nonlinear equations was proposed by an artificial intelligence named Alice.

f1 := x4^3+x5^2*x6-sin(x3)+exp(x1*x2)-5; 
f2 := ln(x4+x5)-x6^2+x3^3-x1^2*x2-2; 
f3 := cos(x4*x5)+x6*sin(x3)-x1*x2^2+x4^2*x5^3;

At the same time, AI accompanied it with comments. Here are some of them:
 

### System Characteristics
 **Underdetermination**: 6 unknowns with 3 equations 

### Solution Complexity

* Lack of a general analytical solution
* Need to use numerical methods
* Possibility of multiple solutions
* Complexity of visualization
* Sensitivity to initial approximations

### Solution Methods

* **Iterative methods**:
* Newton's method
* Simple iteration method
* Gradient methods
* **Numerical methods**:
* Finite difference method
* Monte Carlo method
* Genetic algorithms
* **Optimization approaches**:
* Lagrange multiplier method
* Constrained optimization methods

### Practical Application

Similar systems are found in:
* Quantum mechanics
* Field theory
* Economic modeling
* Bioinformatics
* Machine learning
* Engineering calculations of complex systems

Analyzing such systems often requires specialized software and powerful computing resources.

Although the worksheets provided here have been developed under Maple 2015, they should work correctly with newer versions, except perhaps for commands that use the 'op' function ('piecewise' mainly).

In the sequel the acronym 'pdf' stands for 'probability density function'.


CONTEXT

This post originates from a recent question by @JoyDivisionMan and the ensuing discussion. 

In a few words, the OP noticed Maple 2025 failed to return a result and asked why. In his reply, @acer identified a code regression somewhere in between Maple 2023 and Maple 2025.
Indeed Maple 2023 (which I do not have) provided an answer, just so "my" Maple 2015 did... but thee problem was that Maple 2015's answer was wrong (What is worse? Admit one cannot find an answer or provide a wrong answer?).
 

In this post I explain how we can calculate the result by hand (only elementary maths required), why Maple 2015 (and likely newer versions) returns an incorrect result, why Maple generally fails in returning a result, and finally provide several examples to illustrate that even mathematically simple, the construction of the pdf often requires human intervention (unless a sophisticated AI-driven algorithm is used... at lest in my opinion).

To be clearer, let X some continuous univariate random variable (CURV) and 𝟇 a real valued function from ℝ to ℝ (in the most general sense). Let Y the random variable defined by Y =  𝟇(X).

Here is the main claim: unless very specific situations, you must consider that Maple cannot correctly build the pdf of 𝟇(X) if 𝟇 is not a monotone function (and even sometimes a strictly monotone function).

A few noticeable exceptions are

X any CURV , 𝟇 : x ⟼ x²  (correct solution even if 𝟇 is not monotone)

X ~ Uniform(-1, 1) , 𝟇 : x ⟼ arctanh(x)  (no result returned even if 𝟇 is strictly monotone).

In @JoyDivisionMan's original question it is only by chance that Maple provided the correct result for the non monotone function 𝟇 = cosine ... but it failed for sine function, which motivated the question.




A GOOD DRAWING WORTH A THOUSAND WORDS

Here is a picture to help understand how to get the pdf of Y =  𝟇(X) for a non monotone function 𝟇 (the case of a monotone function directly comes from this latter).

In this illustration X ~ Uniform(0, 2𝜋) , 𝟇 : x ⟼ sine(x).
To ease the explanation, I write X as a mixture of three uniform random variables X₁, X₂, X₃, whose supports are the intervals of the three branches of 𝟇. More formally, X  = (1/4)∙X₁ + (1/2)∙X₂ + (1/4)∙X₃.
The restrictions  of 𝟇 to these three branches are denoted 𝟇₁, 𝟇₂, 𝟇₃.

The large rectangles below the horizontal axis represent the pdf of X₁, X₂, X₃  and the blue curve the 𝟇 function.
The image of the interval [y-dy, y+dy]  by the inverse functions 𝟇₁^(-1) and 𝟇₂^(-1) of 𝟇₁ and 𝟇₂  are represented by the vertical rectangles [x₁-dy, x₁+dy] and [x₂-dy, x₂+dy] .
These two intervals bring a contribution to the pdf of Y (light gray blue on the right) represented by the horizontal violet rectangle on the right side of the picture.

The probability Prob(Y ∊ [y-dy, y+dy]) that Y belongs to the interval [y-dy, y+dy]) is simply the sum 
                 Prob(Y ∊ [y-dy, y+dy])  = Prob(X₁ ∊ 𝟇₁^(-1)([y-dy, y+dy]))  + Prob(X₂ ∊ 𝟇₂^(-1)([y-dy, y+dy]))

Let 𝟇'_b^(-1)(y) denote the derivative of 𝟇_b^(-1)(y).
Making dy tends to 0 gives
                pdf(Y = y)  =  pdf(X₁ = 𝟇₁^(-1)(y)) ×  | 𝟇'₁^(-1)(y) | + pdf(X₂ = 𝟇₂^(-1)(y)) ×  | 𝟇_'2^(-1)(y) |

As I said before there is truly no big math behind this, Except maybe those absolute values?
To understand where they come from zoom in on the rectangle 𝜔 = [x₁-dx, x₁+dx] ╳ [y-dy, y+dy] and denote X_𝜔 and Y_𝜔 the restrictions of X₁ and Y to 𝜔.
Locally Y_𝜔 is proportional to A+B∙X_𝜔 where constant B = 𝟇'(x₁) and the value of constant A does not matter here.
So the pdf of Y_𝜔 is (a classical result)  pdf(Y_𝜔 = y) = pdf(X_𝜔 = (y-A)/C) / |C|.
Few details can be found Here.


MAPLE FAILURES AND WEAKNESSES

So why did Maple, at last some versions, produce a wrong result and why some versions are not even capable to return one?
The reason is that there is no big math only at first sight...because determining the inverse function of 𝟇 can be quite tricky as soon as 𝟇 is not one-to-one map, for instance when 𝟇 is not strictly monotone.
When it is so 𝟇^(-1) must be defined for all the branches whose definition intervals intersect the support of X.

I spent a lot of time debugging the procedure Statistics:-PDF to understand why it either fails or produces incorrec results.
The sine_debug_nodebugoutput.mw  worksheet presents the "X ~ Uniform(0, 2𝜋) , 𝟇 : x ⟼ sine(x)" case (as Mapleprimes stubbornly refuses to upload the worksheet containing the debugger trace, I convert it to sine_debug.pdf to help you see this trace). 
To orient the core development team correcting this procedure (assumming they care), the critical procedures are

Statistics:-RandomVariables:-PDF:-Univariate:-GetValueTab[anything]
and  Statistics:-RandomVariables:-GetInverse
 

At the very end it is this second procedure which is truly responsible of Maple failing to provide a result or returning an incorrect on, because it does not correctly build the inverse functions 𝟇_b^(-1)  for all the branches b which matter.
 

I wrote above that "it is only by chance that Maple provided the correct result for the non monotone function 𝟇 = cosine". Indeed Statistics:-PDF returns a wrong result when X ~ Uniform(z, z+2𝜋) and z is not a multiple of 𝜋/2 (see cosine.mw).

Other important situations where Maple fails returning a result are those where 𝟇 is a polynomial function with different zeros located in the support of X.
I did not trace them but it seems that Statistics:-PDF does not know how to build the 𝟇_b^(-1) in this case (even though it is quite simple, see "Polynomial" examples below).



A SELECTION OF EXAMPLES

Here is a selection of examples to demonstrate that even in rather complex cases the pdfs of 𝟇(X) can be constructed quite easily (note that Maple either fails to compute them or to provide a correct result):

• Three examples where X is a uniform random variable and the restriction of 𝟇 to the support of X is a non monotone polynomial function of increasing degree (the number of branches to consider is equal to the degree of 𝟇):
  Polynomial_function_of_a_random_variable_1.mw,
  Polynomial_function_of_a_random_variable_2.mw,
  Polynomial_function_of_a_random_variable_3.mw
   
• Two examples where the support o  X is unbounded examples and 𝟇 = sine. Here an infinity number of branches must be accounted for, one of these two examples (X ~ Exponential) can be treated in a comple analytic way while the other (X ~ Normal) cannot thus leading to a truncated approximation of 𝟇(X) pdf.
  Infinte_support_sine.mw

OPEN QUESTION

Tracing Statistics:-PDF reveals an already complex algorithm designed to handle a broad variety of "canonical" situations. Even this the algorithm fails in almost all non-toy-problem such as this compilation proves Maple_failures.mw.
At first sight, there seems to be a contradiction between the (apparent?) simplicity with which one can obtain, by hand in sometimes in an ad hoc way, the expression of pdf(𝟇(X)), whether it is exact or truncated, and the complexity of the Statistics:-PDF algorithm, which results in failure in all non trivial cases.

This observation leads to the important question "Is it possible to rewrite Statistics:-PDF in order to enlarge its domain of success?".
I have the feeling that this means designing an algorithm which focuses more on mimicing the human reasoning than identifying "canonical" situations (as it is done today). 
An AI-driven algorithm maybe?

I repeat here that the maths are very simple, and all the more simple if you represent the random variable X as a mixture of components X₁, ... X_B, both having the same (truncated) distribution than X, and whose supports identify to the intervals of definition of the B branches of 𝟇 over the whole support of X.
The only difficulty lies in the identification of these branches and in the construction of the functions 𝟇_b^(-1) over the supports of each X_b.

I have no answer to this question.

In mathematics, us humans love to rely on intuition. It helps us make physical sense of phenomena and guide our thinking before formal reasoning is developed.

For example, approximating the derivative of a function at a point can be thought of intuitively as dividing the function’s rise by its run. As we shorten the distance we run, this ratio approaches the value of the function’s derivative at that point. See this in the demonstration from Maple Learn below.

It is impossible to fully grasp the idea of moving an infinitesimal distance, so we make it easier by asking: “If we move an extremely small distance to the right, how much do we move up?”.

Intuition is typically a beautiful tool for approximating limits, but limits tend to limit (pun intended) the utility of our intuition. A perfect example of this? The Staircase Paradox.

Consider any rectangle you’d like. In the following example, we'll use a rectangle of width 3 and length 4 for convenience, but this paradox extends to any rectangle.

The name of the game is to ask yourself: how far must we walk along the edge of the rectangle to get from the top left corner to the bottom right. Here, the distance is of course 7 units (3 units right and 4 units down). This looks like a bit of a scary fall, so let’s add some stairs.

Even with the stairs, we’re still travelling a total distance of 7 units (1.5 + 1.5 units right, 2 + 2 units down). To shorten the fall even more, we can keep adding more and more stairs.

The important thing to notice is that no matter how many stairs we add, the distance travelled is always 7.

Now you may be wondering, where exactly is the paradox? Well, imagine now we have an infinite number of stairs. Our intuition tells us that our path to the bottom becomes more like a slide instead of a staircase. The steps we take are infinitely small, so it seems like we’re just travelling in a straight line down to the bottom right corner. However, if this were the case, we would have a right triangle! Using the Pythagorean Theorem, the length of our travelled path would be sqrt(3²+4²) = 5.

In other words, our calculations from before were wrong! But... they can’t be wrong, because we saw that the total distance of 7 units travelled was independent of the number of stairs we added.

This is a consequence of something called the “Manhattan distance”, which is the distance you travel if you can only move horizontally and vertically, like navigating the grid of streets in Manhattan. No matter how small we make the steps in our staircase, we are still only moving right and down. We never actually move diagonally. So even though the staircase looks more and more like a straight line, its length is always computed using horizontal distance + vertical distance. The limit of the shapes is a diagonal line, but the limit of the lengths is not the length of that diagonal. And that’s where our intuition stumbles.

The key lesson of the Staircase Paradox is that a sequence of curves can converge to a straight line, while their lengths converge to something completely different.

This is one of the quiet but profound messages of higher mathematics: limits preserve some properties, but not all. Smoothness, shape, and position may converge nicely, while quantities like length, area, or curvature behave in more subtle ways. Mathematics has a gentle way of reminding us that how we measure something can matter just as much as what we’re measuring.

I think there may be a saboteur in the programming/Help department. For a beginner here are some cautions you WILL NOT FIND in Help system.

If you are writing a procedure and wisely choose to include a description:

format must be description " anything here " ;

MUST end with a colon or semicolon 
description MUST be lower case 
the comment MUST be enclosed in double quotes

If you want to view the description of procedure p
you MUST enter Describe (p) because describe(p) will not work nor will description (p);.

In future versions of Maple these rules may change-perhaps

format must be deScriPtiOn " anything here " ;#!!!
and if you want to view the description of procedure p you MUST enter DEsCriBbe ("p') ;

who knows what lies ahead?

Hi there, distinguished audience,

Let f(n)=n²+n+41.

further, require n to be a positive integer.
Look at the cases when f(n) is a prime number, or a composite number.
Beautiful parabola patterns appear.
see attached

writeup_for_prime_producing_trinomial_final.pdf

I also look at the case when there is

n²+n+17.

see

Lucky Number of Euler -- from Wolfram MathWorld

I can be reached by email at

matthewcharlesanderson2@gmail.com

also,

https://mattanderson.fun

Regards,

Matthew

Some mathematical theorems don't just prove a statement to be true, but they reveal something beautiful that itches our intuition. Viviani's Theorem is one of those rare gems. The theorem says something profound but geometrically elegant:

For any point inside an equilateral triangle, the sum of the perpendicular distances from that point to the triangle's three sides is always equal to the height of the triangle.

Take the equilateral triangle below as an example:

By picking any point P, we can draw lines perpendicular to each edge of the triangle that touch point P. The length of these lines always add to 6, which we will discover is the height of this triangle.

To explore this more, former Maplesoft co-op student Michael Barnett made a Maple Learn document on Viviani's Theorem where this is seen in action, as shown below.

No matter where the point P moves, the sum of perpendicular distances from that point to the edges of the triangle always add to the same value: the height of the triangle.

To see why this is the case mathematically, consider the example from before:

More generally, if we let x, y, and z be the shortest distances from the point P inside the triangle to the sides AB, AC and BC, respectively, one can conclude that:

In words, the sum of these distances x+y+z is simply the height of the triangle, h, no matter where the point P lies inside the triangle.

Even after reading this proof, it may be tempting to think of cases where this would not be true. I like to think of Maple Learn as a playground for geometry, algebra and visualization to interact. It helps to convince us that even for many different cases (in fact, all cases!), this theorem holds true.

Viviani's Theorem is a reminder that mathematics isn't always about answers. Instead, it's about finding hidden harmonies that our intuition begs us to question and search for. With tools like Maple Learn, those harmonies buried in symbols and complicated definitions can be uncovered and explored.

If geometry ever felt too distant or abstract, this is your invitation to see it come alive!

We've reached quite a rhythm with Maple Flow - we update frequently, we add lots of improvements and we move fast.

What does this mean for you? It means that the feedback loop between development, the user experience and course correction has a fast time constant.

Without you being loud and vociferous, the feedback loop breaks. So don't be shy - tell us what you want!.

The new 2025.2 update builds on the theme of connectivity with two popular tools - Excel and Python. On top of that, we also have many other features and fixes that you've asked for.

Earlier versions of Maple Flow let you 

• import and and export Excel data from Excel spreadsheets
• run Maple Flow worksheets in Excel with a mouse-driven UI to generate the communication glue

With the 2025.2 update, you can now copy and paste data from Excel into a Flow worksheet.

To be blunt, this is type of cross-application copy-paste behaviour is a no-brainer. It's such a natural workflow.

We've increasignly found that Python is now being used to script the interaction and data flow between different engineering tools. With Maple Flow 2025.2, you can now execute Maple Flow worksheets from a Python script. 

From Python, you can change and export any parameters and results defined in the worksheet

This gives me the dopamine hit of watching CPU utilization spike in the Task Manager (hey..I get my kicks where I can)

You can now do your parameter sweeps more quickly by executing the same worksheet in parallel, changing parameters for every run.

This is easy to set up - no special programming is needed.

• Print Extents can now be set globally for all sessions, or just for the current session.
• Any user-installed fonts used in the worksheet are now respected in the PDF export
• Worksheets execute faster
• The update includes fixes to many user-reported issues

You can install the Flow 2025.2 update via Help > Check for Updates (or if you're not already in the race, then grab a trial here and take Flow for a spin).

We're not pulling back on this aggresive development velocity, but we need you to point us in the right direction. Let's keep the feedback time constant small!

While conducting a workshop for business calculus students one day, I was reminded of a familiar challenge. Many students approach calculus with hesitation, especially those in business programs who may not see themselves as “math people.” Even when they are following the steps, it is not always clear that real understanding is happening.

During the workshop, we were discussing inflation as an example of exponential growth. I wrote the model on the board and explained how prices increase over time. Students were taking notes, but their expressions suggested they were still trying to connect the formula to its meaning.

So I opened Maple Learn.

I entered the equation, and the graph appeared right beside it. Almost immediately, the mood in the room shifted. One student leaned forward and said, “Oh… that’s what inflation looks like over time.”

That simple moment captured why visualization matters so much in calculus.

One of the strengths of Maple Learn is how naturally it combines symbolic work and graphical representation in a single space. Students can write equations, perform calculations, and see the corresponding graphs without switching tools. This makes abstract ideas feel more concrete and easier to interpret.

Maple Learn also works well as a note-taking tool. During the workshop, students kept their formulas, graphs, and written explanations together in one organized document. Instead of passively copying, they were actively building understanding as they worked through the example.

What stood out most was how easily students began sharing their work. They compared graphs, discussed small differences in their models, and asked one another questions. The technology supported conversation and collaboration, helping create a sense of community rather than isolated problem-solving.

By the end of the workshop, students seemed more confident and engaged. The combination of visualization, structured note-taking, and peer sharing helped transform a challenging topic into something accessible and meaningful.

Experiences like this remind me that when students can see mathematics, talk about it, and learn together, calculus becomes far less intimidating and far more powerful.

As a calculus instructor, one thing I’ve noticed year after year is that students don’t struggle with calculus because they’re incapable.

They struggle because calculus is often introduced as a list of procedures rather than as a way of thinking.

In many first-year courses, students quickly become focused on rules: differentiate this, integrate that, memorize formulas, repeat steps. And while procedural fluency is certainly part of learning mathematics, I’ve found that this approach can sometimes come at the cost of deeper understanding.

Students begin to feel that calculus is something to survive, rather than something to make sense of.

Research supports this concern when calculus becomes overly mechanical; students often miss the conceptual meaning behind the mathematics. That realization has pushed me to reflect more carefully on what I want students to take away from my class.

Over time, I’ve become increasingly interested in teaching approaches that emphasize mathematical thinking, not just computation.

Thinking Beyond Formulas

When I teach calculus, I want students to ask questions that go beyond getting the right answer:

1. What does this derivative actually represent?
2. How does the function behave when something changes?
3. Why do certain patterns keep appearing again and again?

These kinds of questions are often where real learning begins.

In The Role of Maple Learn in Teaching and Learning Calculus Through Mathematical Thinking, mathematical thinking is described through three key processes:

1. Specializing - exploring specific examples
2. Conjecturing - noticing patterns and testing ideas
3. Generalizing - extending those patterns into broader principles

This framework captures the kind of reasoning I hope students develop as they move through calculus.

What Helps Students See the Mathematics

One of the biggest challenges in teaching calculus is helping students see the mathematics, not just perform it.

It’s easy for students to get stuck in algebraic steps before they ever have the chance to build intuition. I’ve found that students learn more effectively when they can explore examples, visualize behavior, and experiment with ideas early on.

Sometimes that happens through discussion, sometimes through carefully chosen problems, and sometimes through interactive tools that allow students to test patterns quickly.

The goal isn’t to replace thinking it’s to support it.

A Meaningful Example

One activity highlighted in the study, Inflation and Time Travel, places exponential growth into a context students can relate to: wages and inflation.

When students adjust values, observe trends, and ask what happens over long periods of time, calculus becomes much more than an abstract requirement. It becomes a way of understanding real phenomena.

Activities like this remind students that mathematics is not just symbolic work on paper; it is a way of describing and interpreting the world.

Final Thoughts

For me, calculus is not meant to be a barrier course.

It’s meant to be a gateway into powerful ways of reasoning about change, structure, and patterns.

When students begin to specialize, make conjectures, and generalize ideas for themselves, they start to experience calculus as something meaningful, not just mechanical.

And as an instructor, that is exactly what I hope to cultivate in my classroom.

If one of our posts showed up in your social media feed recently, you may have found yourself staring at a giant maple leaf with feet and thinking, “Wait… who (or what) is that?” you’re not alone. 

Yes, that big, cheerful leaf you’ve been seeing is very real. 
And yes, they have a name. 

Meet Mathy. 

We officially introduced Mathy to the world a couple of weeks ago at JMM 2026 in Washington, DC, but their story actually started much earlier. 

Mathy was originally created by one of our developers, Marek Krzeminski, a few years ago as a fun internal character. Over time, they quietly became our in-office, local mathscot, popping up as mini 3D-printed Mathys around the office and even as a custom emoji someone created. 

Then, sometime last year, someone had what can only be described as a bold idea: 

What if we brought Mathy to life? 

And just like that, the giant maple leaf went from concept to costume. 

Mathy is fun, curious, and a little playful. That’s very intentional. That’s what math should feel like. 

We believe math matters. We also believe math should be approachable, joyful, and a place where curiosity is rewarded. Mathy reminds us, and hopefully others, that math doesn’t have to be intimidating. It can be fun, and it can inspire awe. 

I’ll be honest. When we decided to bring Mathy to JMM, I was a little nervous. Conferences are busy, serious places. Would people really want to interact with a seven-foot-tall maple leaf? 

As it turns out, yes. Very much yes. 

Researchers (from postdocs to seasoned academics), educators, and undergraduate and graduate students all stopped, smiled, laughed, and asked for photos. At one point, people were actually lining up to take pictures with Mathy.

Let’s just say: Mathy was a hit. 

How tall is Mathy? 
About 7 feet. They are hard to miss. 

What does Mathy love (besides math)? 
Dancing. Very much dancing. 
You can see for yourself here: Mathy's got moves!

Does Mathy talk? 
You bet they do. 

Now that Mathy has officially been introduced to the world, you’ll be seeing them more often on social media, at events, and in a few other fun places we’re cooking up. 

So if you spot a giant maple leaf dancing, waving, or talking math, now you know who they are. 

If you spot Mathy, don’t be shy, say hi. 

Many problems in mathematics are easy to define and conceptualize, but take a bit of deeper thinking to actually solve. Check out the Olympiad-style question (from this link) below:

Former Maplesoft co-op student Callum Laverance decided to make a document in Maple Learn to de-bunk this innocent-looking problem and used the powerful tools within Maple Learn to show step-by-step how to think of this problem. The first step, I recommend, would be to play around with possible values of a and b for inspiration. See how I did this below:

Based on the snippet above, we might guess that a = 0.5 and b = 1.9. The next step is to think of some equations that may be useful to help us actually solve for these values. Since the square has a side length of 4, we know its area must be 4² = 16. Therefore, the Yellow, Green and Red areas must add exactly to 16. That is,

With a bit of calculus and Maple Learn's context panel, we can integrate the function f(x) = ax² from x = -2 to x = 2 and set it equal to this value of 8/3. This allows us to solve for the value of a.

We see that a = 1/2. Since the area of the Red section must be three times that of the Yellow (which we determined above to be 8/3), we get Red = (8/3)*3 = 8.

The last step is to find the value of b. In the figure below, we know that the line y = 4 and the curve y = bx² intersect when bx² = 4 (i.e. when x = ± 2/sqrt(b)).

Since we know the area of the red section is 8 square units, that must be the difference between the entire area underneath the horiztonal line at y = 4 and the curve y = bx² on the interval [-2/sqrt(b), 2/sqrt(b)]. We can then write the area of the Red section as an integral in terms of b, then solve for the value of b, since we know the Red area is equal to 8.

Voila! Setting a = 1/2 and b = 16/9 ≈ 1.8 guarantees that the ratio of Yellow to Green to Red area within the square is 1:2:3, respectively. Note this is quite close to our original guess of a = 0.5 and b = 1.9. With a bit of algebra and solving a couple of integrals, we were able to solve a mathematics Olympiad problem!

This post stems from this Question to which the author has never taken the time to give any answer whatsoever.

To help the reader understand what this is all about, I reproduce an abriged version of this question

I have the following data ... [and I want to]  create a cumulative histogram with corresponding polygon employing this same information...

The data the author refers to is a collection of decimal numbers.

The term "histogram" has a very well meaning in Statistics, without entering into technical details, let us say an histogram is an estimator of a Probability Density Function (continuous random variable) or of a mass function (discrete random variable), see for instance Freedman & Diaconis.

The expression "cumulative histogram" is more recent, see for instance Wiki for a quick explanation. Shortly a cumulative histogram can be seen as an approximation of the Cumulative Density Function (CDF) of the random variable whose the sample at hand is drawn from.

In fact there exists an alternative concept named ECDF (Empirical Cumulative Distribution Function) which has been around for a long time and which is already an estimator of the CDF.
Personally I am always surprised, given the many parameters it depends upon (anchors, number of bins, binwidth selection method, ...), when someone wants to draw a cumulative histogram: Why not draw instead the ECDF, a more objective estimator, even simpler to build than the cumulative histogram, and which does not use any parameter (that people often tune to get a pretty image instead of having a reliable estimator)? 

Anyway, I have done a little bit of work arround the OP's question, and it ended in a procedure named Hodgepodge (surely not a very explicit name but I was lacking inspiration) which enables plotting (if asked) several informations in addition to the required cumulative histogram:

• The histogram of the raw data for the same list of bin bounds.
• The kernel density estimator of this raw-data-histogram.
• The ECDF of the data.

Here is an example of data

and here is what procedure Hodgepodge.mw  can display when all the graphics are requested

Hello all,

This is a post for a software change.

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

i++

++i

i--

--i and idem for multiply and divide.

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

i++ does work however.

Have a great day.

Jean-Michel

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

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

Thank you

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

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

20 YEARS and nothing changed.

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

Even the article above says this

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

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

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

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

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

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

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

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

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