@jalal If I've correctly understood your followup query then here is one way:

TESTQCMal_ac.mw

@opus64 The phrase "does not contain" is a structural reference. It means that c[n]*(e+f[n]) is not structurally present as a subexpression. Yes, it may be mathematically present, but that's not the same.

That is why I used simplify with side-relations to do a temporary substitution. (There are other ways to get temprary substitutions of compound terms, eg. using freeze & thaw.)

Some notes, which you may (or may not) find useful: Download struct_note.mw

For your farther goal of automatic handling in cases where you don't specify the subexpression (but it gets handled automagically), it might be much better if you could provide one or more much more involved examples. Your first example is so simple that several simplistic coding attempts could find that target subexpression but still fail on some or most or all or your later examples. It's best to provide a hard example for stuff like this, not an easy one.

Show an example of what you are trying to accomplish.

@mmead Thanks for the worksheet. (Providing detailed requirements almost always helps more.)

It might be possible to do something cleaner (for you to use) with objects. If I get something I'll show it. Alas, my time is limited these days.

@mmcdara Using the single command implicitdiff is more direct than your use of five different commands (alias, diff, isolate, map, and factor). 

It's also easier to remember, to type in. Being simpler also makes its use less error-prone and more straightforward to reuse.

These advantages are the central reason why many single commands exist in Maple and other programming languages.

@The function What do you think about the denominator 2*y^3+6*x*y , compared with 2*y^3+6*x as shown in the textbook?

@The function Actually, I meant that you should compare against the solution provided by the textbook, term by term.

Seriously, do that.

How do each compare with your solution done by hand, say?

@The function I suggest that you check the answer.

You could also study the Help page for the implicitdiff command.

Also, you would benefit from browsing the "See Also" cross-reference links when you are looking through the Help system. For example, a link to the Help page for implicitdiff shows in the "See Also" when you look at the Help page for diff (differentiation).

Upload and attach your example.

@alex_b That looks good for the textplot. Actually, the wrapping call to typeset is not necessary, in at least most recent versions.

I forgot to mention in my Answer that wrapping in Typesetting:-mn makes it prettyprint nicely even in regular output, apart from any plotting. Otherwise (as you have it, quoted) the quotation marks show up in regularly typeset 2D Output.

Starting with the idea in the Answer by Rob Corless to divide by U__0, we could make a further adjustment.

By further specifying rescaled axis tickmarks (effectively now also multiplying by U__0) we can once again get a plot of U(t) -- which is what the textbook requested. Now U__0 is marked on the vertical axis, even if it is an unassigned symbolic name.

Download initial_U0.mw

or,

I have submitted a bug report against this regression (apparently in hardware float mode).

I have also submitted a separate report against the following (which fails for my Linux in Maple 2015.2, 2018.2, and 2021.1 and might not be a regression).

restart; Digits:=20:
with(Statistics):
Histogram(Sample(Poisson(200),34508));
Error, (in Statistics:-Histogram) Segmentation Violation occurred in external routine

@erik10 I believe that the smoother performance is mostly due to the lesser burden on the GUI plot renderer.

I reduced the first value in the grid option of the densityplot call, from 49 down to 19. The GUI itself does some shading interpolation when rendering densityplots, so the horizontally coarser grid is cheaper but not visibly much coarser in appearance.

The second value, 2, was already as small as allowed. It can be so small because the color shading does not vary according to vertical position.

The computational transformation -- from a rectangle to the region below the curve -- is also less expensive for a coarser grid. A hand-tailored transforming routine might make that part a bit faster, but I wouldn't be surprised if GUI rendering overhead were still noticeable.

@erik10 Some more ideas to play with. The slider's action behaves a little more smoothly with the following, and the Slider's length is greater and a little easier to manage, etc.

Planck_curve_ac2.mw

@The function The other direct command (that I gave for your earlier problem) handles this newer example.

Student:-Calculus1:-Roots(tan(Pi/2 - x) - 4.6785, x = 0 .. 2*Pi, numeric);

              [0.2105750775, 3.352167731]

See my explanation above for how each works internally. This newer example is harder for NextZero (ie. fsolve with maxsols in your Maple), while the recursive fsolve approach of Calculus1:-Roots does better. There are also examples which Maple can solve but which stymie the calculators you mention. All numeric methods have some problematic cases.