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.

The reason you didn't see the effect on your plot3d result is that none of the input points has alpha in that same problematic range as has your plot result.

Your plot3d result has a range of 0..15 for alpha. And the default grid size is 49x49. However, none of these 49 generated values for alpha in that special range just below 0.1.

seq(0 .. 15.0, numelems = 49);

   0, 0.3125000000, 0.6250000000, 0.9375000000, 1.250000000, 
     1.562500000, 1.875000000, 2.187500000, 2.500000000, 
     2.812500000, 3.125000000, 3.437500000, 3.750000000, 
     4.062500000, 4.375000000, 4.687500000, 5.000000000, 
     5.312500000, 5.625000000, 5.937500000, 6.250000000, 
     6.562500000, 6.875000000, 7.187500000, 7.500000000, 
     7.812500000, 8.125000000, 8.437500000, 8.750000000, 
     9.062500000, 9.375000000, 9.687500000, 10.00000000, 
     10.31250000, 10.62500000, 10.93750000, 11.25000000, 
     11.56250000, 11.87500000, 12.18750000, 12.50000000, 
     12.81250000, 13.12500000, 13.43750000, 13.75000000, 
     14.06250000, 14.37500000, 14.68750000, 15.00000000

Note that your RootOf expression contains no information that would indicate to fsolve (which is called by `evalf/RootOf`) which root is desired, or what range to compute over or take initial values from, etc.

But you could add a range descriptor to the RootOf. In this example it happens that we can figure out that the roots are either negative or positive, for your range of alpha. So that helps.

Note that in your original example fsolve gets called (for each numeric alpha value) without any specified range. But in the edit below it gets called with the range 0.0..infinity, and only the positive roots get found.

Download plot_of_RootOf_ac.mw

You can verify my explanation by setting trace(fsolve) and then calling it like the following (for your original RootOf without range descriptor, and also for my edit that has it),
    plot(a, alpha=0..0.5, adaptive=false, numpoints=7)

And you can verify my comments about plot3d in a variety of ways (including specifying the very same alpha range, or increasing the grid, etc).

Here attached are a few approaches. But first a few notes:

I don't yet see a nice+easy+sensible+robust way to "simplify" more general things like,
    2 - cos(x)^2 - cos(y)^2
into,
    sin(x)^2 + sin(y)^2
without also clobbering standalone terms like cos(v)^2 into becoming 1-sin(v)^2 undesirably.

Part of that relates to the fact that simplify doesn't use directly measured expression size and comparison as its main/only aspect for all mathematical simplification (trig, radicals, etc). The purer size compression & comparison focus is more for arithmetic/polynomial restructuring (ie, `simplfy/size` which it now does as a finishing/polishing step).

I wonder whether the procedure K below might be more generally useful to the OP than the other approaches attached. That just allows simplify to do its thing, then patches up that csgn split, after-the-fact.

So, fwiw,

Download simp_trig_ex9.mw

In the Maple 2025 ribbon, choose,

    Edit -> Editing -> User Profile

and in the pop-up dialog that appears choose "Engineering Notation" from the drop-menu.

Then close that with Apply And Set As Default

After that, in newly opened sheets you should get it by default.