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.

The example illustrates a weakness in `simplify`.

With a little help, the `odetest` result can be simplified to zero, using `simplify`.

Below, I also give a few other examples with similar weakness.

Download nm_simplify_27122025_ac.mw

Some of the examples I find interesting because simplify can produce 1 for the ratio of two terms, while not being able to produce 0 for their difference.

The effect you're seeing is the effect of uniquification by the Maple kernel. It's not just about the display of the expression; it's about how Maple stores its unique structural representation in memory.

The effect you're seeing is the fundamental storing and unique representation that the Maple kernel does for the  Directed Acyclic Graph (DAG) representations of expressions it has a session. It stores the DAGs in a hashed data structure. That structure is sometimes called the "simpl" table.

Yes, this is to ensure that all equivalent expressions are stored only once in memory. But it is not a table in the usual sense for the Maple language, and there is no general purpose, direct access mechanism to it for the user.

It is not a "remember table", which is a feature of PROC DAGs. Those are accessible as a table. It is not that. There is no remember table to forget.

The sort command allows for some in-place replacement of the representation of an object in that internal "simpl" table. If the unique representation is changed, then it appears changed anywhere else where that very same DAG is accessed/pointed-to, or in any new created DAG that contains it. But the sort command only allows one to sort with respect to certain kinds of expression.

If your use of eval returns an expression whose DAG contains an already existing/simpl'd DAG then the new instance of the (sub)expression will be the same as what was already simpl'd.

Some examples,

Download sort_fun_2.mw

Download sort_fun_3.mw

Download nm_ode_ex1.mw

You could try the option,

    obsrange=false

Is there a reason that you don't use plots:-odeplot instead, or allow for any adjustments to control the error?

The enlargement of the y-range that allows this particular example to work as you expected (without obsrange=false) seems much smaller than 10% which you used.

Also, you haven't supplied an example in which you need the y-range. You've claimed that you sometimes run into issue without it, but haven't provided examples.

ps. Is there a specific reason for all that `op` and `originalview` stuff, as opposed to, say, using plottools:-getdata with its rangesonly option?

Some years ago the so-called "typesetting rule" for some special functions (like the Bessel family) was changed from true to false by default.

That Help page you've cited appears to not have been updated accordingly.

But you can still enable it using:

  Typesetting:-EnableTypesetRule("BesselJ")

(or, I suspect, by using the RuleAssistant dialog from that same package).

Download Typeset_ac.mw

Those errors all occur in Maple 2024.2

But in Maple 2023.2.1 they get solved (and they solutions satisfy the equations).

Here's another way to actually compute the integral, with a check, if we consider tau to be real-valued.

The result is attained in that first line of computation.

The result prints reasonably nicer in the actual Maple GUI, and computation is overall reasonably quick.

Download nm_int.mw

There are some variants, trading off, say, continuity at (some) points versus compactness, according to piecewise constants for the three regions obtainable by splits at tau=-1 and tau=1.