Maple uses a extension mechanism for some kernel builtin commands like expand. This recognizes procedures with a name in a pattern like `expand/f` to be the thing to use when asked to expand a call to f.

There is a default Library procedure assigned to `expand/Sum`. That is a somewhat complicated procedure that tries a bit to respect the notion that expanding (splitting) a Sum is not always mathematically valid.

When you load a command from the old student package (using with, like you've done) Maple does some initialization of the package and redefines some things. In particular, it redefines `expand/Sum`.

It actually redefines it as a call to readlib of the new, replacement procedure. That's not key. What's key is that the initialization assigns another, simpler procedure to `expand/Sum`. That new procedure turns a Sum call of an addition of terms into an addition of Sum calls, regardless of the fact that is not always right. I suspect that the rationale was the students would find the functionality useful, and were less likely to be working with divergent sums (infinite series), etc, or that the benefit of the functionality outweighed the danger.

You can compare these:

restart;
interface(verboseproc=3):
with(student,changevar);
showstat(eval(`expand/Sum`));

restart;
interface(verboseproc=3):
showstat(`expand/Sum`);

Here are various corrections and adjustments, including:

- Utilize the nolines option to plots:-inequal, to get rid of dotted line demarking part of one strict inequality.
- Utilize InertForm:-Display for (right tick) unevaluation-quoted expressions used in the plots. Otherwise, subsequent re-use or evaluation of the created plots will cause those nicely formatted names in inequalities to evaluate to lengthy expressions. NB. the typeset option does not(!) prevent that. You can test this worked by just assigning the plot to a name, and then printing that after the fact; it's working properly if the inlined math in the plot survives.
- Get rid of some unnecessary quotes.
- Pass gridrefine=4 on to implicitplot, called from plots:-inequal, to get smoother edges of polygon regions.

Download Question_1_regional_ac.mw

Here is a further revision of Carl's revision of Kitonum's procedure.

The main point of this revision is to allow the same kinds of color functionality (for the curves and the text contour labels) as contourplot has for its curves.

(Aside: If you have an old version which does not support the colorbar option -- on densityplot or contourplot -- then you could just remove those from the code. The code below references it just to disable it.)

Download CPL03.mw

And your other example,

ContoursWithLabels(
     y^2+x-1, x=-10..10, y=-10..10, contours=[$-1 .. 5],
     TextOptions = [font=[HELVETICA,BOLD,7], color="DarkBlue"],
     ContourOptions = [colorscheme="DivergeRainbow"]);

ContoursWithLabels(
     y^2+x-1, x=-10..10, y=-10..10, contours=[$-1 .. 5],
     TextOptions = [font=[HELVETICA,BOLD,10]],
     ContourOptions = [colorscheme="DivergeRainbow"]);

ps. I notice that my M2024.2 has trouble rendering the minus sign in a textplot numeral/float, when the font size is 8 or 9. Not central to this code, but I'll report it.

I'm not suggesting that this is a good choice of template function. It's merely an illustration, a bit like you had.

Not also that NonlinearFit might do local optimization, so quality of the fit can depend on the choice of initialvalues. See also the DirectSearch v.2 package on the Application Center, which can do similar kinds of fitting but doing global optimization over supplied parameter ranges.

notes:
- The randomize() call makes it get a different L after each restart.
- The float range -5.0..5.0 makes it produce floats in the range. A range -5..5 would just produce integer values in the range.

Download Mma_trans_01.mw

Your original example can be handled like so:

f:=x^2 - y^2+Pi;

               2    2     
         f := x  - y  + Pi

indets(f,And(name,Not(constant)));

              {x, y}

A variant, to disregard "dummy" variables (or integration, summation, say),

Download indets_name_1.mw

The DEplot command is solving the ode numerically. That incurs small numeric error, which is not unexpected.

But if the approximated solution of y(t) goes even slightly outside of your forced restricted range y=-1..1 then the numeric solving (and, here, DEplot which calls it) halts.

Try it without the enforced range on y.

ode := diff(y(t), t$2) + y(t)=0;
DEtools:-DEplot(ode, y(t), t=0 .. 3*Pi,
                [[y(0)=1,D(y)(0)=0]],linecolor=blue);

Or, you could use the option obsrange=false.

DEtools:-DEplot(ode, y(t), t=0 .. 3*Pi,
                y=-1..1,
                obsrange=false,
                [[y(0)=1,D(y)(0)=0]],linecolor=blue);

This is the same underlying issue as in your Question of Dec 14, 2025.

ps. In this later example, the fact that it happens to work with t=0..round(3*Pi) is somewhat of a fluke -- the sampled points just happen to not stray just outside your supplied strict y-range.
pps. I am not sure why your previous example didn't motivate you to use obsrange=false if you are going to supply a forced, tight y-range.

Another possibility for programatically stacking items/lines that appear at the bottom is to use the caption option.

IIRC stacked items can also be justified or aligned (by the colored lines, or even the equal-signs), possibly using an html-ish mtable, but I'd have to search old notes for how I did that programatically.
 

Download caption_for_legend.mw

ps. This comes out of old idea to use caption for getting legend effects
on 3D plots.
pps. On a side note, does captionfont work with setoptions? I'll check, and submit an scr if needed. 

The left-quotes are not necessary.

The 2D Input can be done just be using a single right-quote (apostrophe) for the prime.

One can even change a setting so that the derivatives appear in prime-notation in 2D Output.

Download typeset_prime_2D.mw

Yes, when simplify manipulates an active (non-inert) limit call then transformations it makes produce new active limit calls -- which evaluate as usual.

That's not unusual. It happens (sometimes very productively) for active int calls as well.

Here limit might not be able to handle an expression with, say, tan&sec forms. That's a limit weakness more than it is a dsolve weakness. Your phrase, "...since dsolve could not find limit..." suggests that you're blaming dsolve for limit's weakness -- which would be a mistake.

If you convert this sol result to sincos, and then evaluate that, then limit can compute that the limit is undefined. Eg,
     eval(convert(sol,sincos))
There's no completely general reason for simplify not to attempt that kind of transformation, and in doing so allow limit to attain an explicit result that it couldn't get for the original form.

Ideally, limit itself could have found that result (including when dsolve calls it to do that task).

The following code may illustrate limit's failure (under dsolve) and then later its success when simplify forces transformations (which limit itself might ideally have tried originally, etc):

ode:=4*x*diff(y(x),x$2)+2*diff(y(x),x)+y(x)=(6+x)/x^2;
IC:=y(infinity)=0;

trace(limit);

sol:=dsolve([ode,IC],y(x));

simplify(sol);

Now, it can happen that MultiSeries:-limit can find an explicit undefined result directly from the expression containing the tan form. If a limit call would return that then dsolve could return NULL. (Again, this is about weakness in what :-limit may FAIL on, more than what dsolve's doing here.)

restart;
ode:=4*x*diff(y(x),x$2)+2*diff(y(x),x)+y(x)=(6+x)/x^2;
IC:=y(infinity)=0;

unprotect(limit):
limit:=MultiSeries:-limit:
protect(limit):
trace(limit):

sol:=[dsolve([ode,IC],y(x))];

That seems weird. I think you could submit a bug report on that.

ps. consider y(x) = exp(-x)  (which I got by looking at it...)

Download de_inf_ex.mw

Do you mean this one?

proc(f,x,y,ndata,nvars)
   local G,init,nparams,k;
   nparams := nops(f);
   init := `if`(type(x, 'Vector'), (i,j)->evalf(f[j](x[i])),
                  (i,j)->evalf(f[j](seq(x[i,k], k=1..nvars))));
   G := Matrix(ndata, nparams, 'datatype'=float, init);
   LinearFitting:-LinearLS(y, G, ndata, nparams, args[6..-1]);
end proc;

I think that it might be a local of an unnamed(?) module which also contains an overloaded LinearFit (to which the export LinearFit of Statistics:-Regression somehow refers...).

You can enter it, in a debugger run of a LinearFit call, and list its contents.

You can use items from the Palette menus for this, which appear in the left panel of the Maple GUI.

In the special case that it is an arrow that you want on top then you can find a dedicated entry for it on the Accents palette.

You could also first enter the appropriate stacked item (template) from the Layout palette. Replace the lower portion by u, and the upper portion by your choice from the Arrows palette.

You can use the Tab key (or mouse pointer) to move focus around the entered item.

You can manage which of the many available palettes appear in the left panel, using GUI's main menu/ribbon.

The odetest result can be further manipulated and simplified to zero under assumptions.

In my Maple 2024.2 it can get it, assuming x::real

In my Maple 2022.2 it can get it, assuming x::posint, though that raises an error like yours in 2024.2.

In that Maple 2022.2 it gets it around 4 out of 5 times (after restart) for x::real, but always gets it for x>0.

Download nm_odetest_ex3.mw

Ideally simplify or odetest itself would be able to get the zero directly, either under assumption x::real, or under assumption x::posint.

You can insert a reference to an Equation Label using Ctrl-l , or Command-l on Mac OS X. (That's Ctrl and the "L" key.)

No, not all versions have a dedicated "What's New" page just for differential equations.

The general layout and naming of these pages changes, and is not fixed.

Some releases have a specific section for DEs in the "Advanced Math" What's New page. It depends on how much was new in that functionality.

The areas of focus for development change over time.