This is one way to get what you asked, "captions fig.1,fig.2,fig.3,fig.4 in the Tabulate command ( variable G) without taking into account the random order of the graphs".

TEST_-_Copie_ac1.mw

Hopefully you have asked for that which you actually want.

Here is one way that your example can be handled.

Download isolate_ex.mw

You could also use solve instead of isolate. Variations can handle some cases where there are multiple solutions from solve. For some examples algsubs could be used instead of simplify (simplify with side-relations), to do the temporary substitution by a dummy name.

Are you also going to have examples where you want to treat the (smallest?) arithmetic subexpression that contains the target names, eg. both c[n] and f[n] present, say, but without your having to specify that explicitly? A clear and precise characterization of your possible examples may help.

I'm not sure that I understand your scenario. But perhaps this is close.

(edit: I am not providing you with the direct approach of simply multiplying a symbol by a unit, eg. pp:=p*Unit(m). I had imagined that you were asking about something more complicated.)

Download units_hidden.mw

The implicitdiff command gives the following, directly and staightforwardly.

Download implicitdiff_ex.mw

Firstly, try not to use the word "function" if you find yourself in a muddle with expressions (that depend on name t) versus operators (whose formal parameter dummy name just happens to be t). Otherwise you might be using the word ambiguously.

Download differentiation_expr_vs_operator.mw

Also, note that Diff is an inert version of active diff. Your goal is to actively differentiate, so using inert Diff would just add more muddle here.

Here are a few ways. I used the second (red code) in the plot on the right.

I moved the angle textplot a little to the left, and reduced the font size to 14.

Download QuestionTypeset_ac.mw

You seem to be mistakenly conflating this GetEquations functionality with this older (deprecated) GetEquations functionality that has a different usage and syntax.

The names "foo" and "bar" are convenient short names, where the general idea is that people may recognize them as being offhand, disposable, example names.

See foobar and FUBAR, which respectively give the letter "r" as standing for "repair" and "recognition". I am more familiar with the latter.

You have to supply the initial voltage, if they don't provide it for you. Otherwise your function U(t) will not output values that are numeric. You need numeric values for plotting. That should not be surprising.

[edit] I'll note that part a) says to plot the graph of y=U(t).

You wrote, U(t)=cos(2t)*U*e^t/10, but that's not what the text image shows! The text uses a "U" with subscript "0" on the right-hand side. That's a common way to represent the initial value (constant), and is intended to be a distinct name and not the same as the "U" on the lhs.

The initial voltage should not be assigned to a name that depends on the same name U as used for the procedure. So, in Maple, U0 or U__0 would be ok, but U[0] is asking for trouble.

Note that U__0 (double underscore) prettyprints with a subscript. (See also here for shortcuts).

In this attachment I typed the keystrokes U__0 to get the subscripted name in 2D Input.

Download initial_U.mw

Download fencing.mw

Here are various ways (since you explicitly asked about select, and a loop).

Download list_selection.mw

[edit] If you only want the first element that satifies the condition (or if you know that your list has at most one such element) then there are approaches that can be faster. It can be beneficial to break out of the search as soone as one element is found. For example, comparing with the original seq approach,

Download list_selection_singleton.mw

The procedure shown as IPP:-Convolution is a local member of the IPP submodule of the SignalProcessing module (package).

Here are two ways that you can inspect its (initial) form.

restart;
showstat((SignalProcessing::IPP)::Convolution);

Convolution := proc()
   1   passign(procname,defun(convert("Convolution",'string'),"msp",(':-mtsafe
         ') = true));
   2   procname(_passed)
end proc

restart;
kernelopts(opaquemodules=false):
eval(SignalProcessing:-IPP:-Convolution);
kernelopts(opaquemodules=true):

proc()
   option THREAD_SAFE;
   passign(procname, defun(convert("Convolution", 'string'), "msp", ':-mtsafe' = true)); procname(args)
end proc

That somewhat obscure-looking code serves the purpose of rewriting the procedure's own body the first time it gets called.

SignalProcessing:-Convolution(Array([5,7]),Array([-2,6,10])):

kernelopts(opaquemodules=false):
eval(SignalProcessing:-IPP:-Convolution);
kernelopts(opaquemodules=true):

proc()
   options call_external,
           define_external(mspConvolution, MAPLE, LIB = "libmsp.so", THREAD_SAFE);
   call_external(0, 140184961382080, true, true, args)
end proc

The first time it gets called it sets itself up and replaces itself with a so-called external-call, ie. a call out to a precompiled external dynamic library. In this case it is an external-call to a bridging function, and the module name IPP suggests that the bridge is to a suitable function from the Intel IPP Library (Integrated Performance Primitives), containing highly optimized functionality that includes signal processing.

Your attachment doesn't provide your own method for shading under the curve, even for any fixed T value. You said you knew how to combine that with the curve using plots:-display, but didn't provide any example of just what you meant. So I'll supply something crude for that part of the task.

Here are a few ways. One of them calls densityplot dynamically, for each new "explored" value. The other computes a sole densityplot up front, and then transforms that to fit under your curve.

Also the first uses WavelengthToColor from the ColorTools package, while the second uses a linear hue gradient (which is of course not quite right). You may have your own wavelength->hue method. I am not satisfied with the values from WavelengthToColor, but I am having trouble finding my own version written many years ago...

You can experiment with various combinations, to see which gets you the smoothest action under a continuous movement of the Slider. If the code is too slow to compute each frame (for each T value) then continuously moving the Slider will produce a computational backlog and make the action appear jilted. In such a case you could toggle off continuous-updating of the Slider, having it only compute once, after the Slider is finished its move. But a continuous update is more visually impressive, if the frame computations are fast enough to allow it.

You could mix and match the apporaches: transformation of a single precomputed densityplot, or dynamically generated densityplots -- either of those using any wavelength->hue scheme mentioned above, or your own.

You could also call Explore directly on some of the plots:-display calls, without need for name procedures (foo, blah). I prefer such custom procedures because then I can test them by calling them outside of Explore.

Download Planck_curve_ac.mw

It is also possible to use the full qualities of the colors, ie. also use their intensity and saturation, and not only their hue (with maximal intensity and saturation). Perhaps its prudent to wait for complete details of what you want to accomplish, and what you want the colors to represent in terms of power or perception.

My Maple GUI sometimes gets into this state.

If I shutdown the GUI (either using the menu, or the corner Close icon) then it (almost always) prompts me whether I want to save the open worksheet. If the worksheet was not yet saved as a filename then usually it prompts me for a filename at that point.

If that works then I can Relaunch the GUI and then Reopen the saved worksheet.

A rare scenario is that it gets into the problem state but doesn't allow me to save. Hopefully that is not your case.

Here are various ways.

Obtaining floating-point approximations is relatively easy, and two direct ways are shown, ie. straight calls to a single command. The fsolve example relies on guessing an overestimate of the number of roots. The Calculus1:-Roots example doesn't require such as guess.

Obtaining all the roots in 0..2*Pi, in exact form, is also shown, in a few ways that have varying success and complexity. These kinds of computation can involve using fortuitous simplifications -- sometimes both before and after substitution. (Discovering a sufficient simplification is one aspect that can make this tough, for both the user and Maple's own symbolic solvers.)

Download solve_trig_ex.mw

[edit] The above was done in Maple 2021.1. In my older Maple 2019.2 getting the nicer exact form of (some of) the results from the second calls to Calculus1:-Roots required a slightly different simplifying concoction, eg.
    simplify(evala(simplify(convert(ans2b,expln))))
solve_trig_ex_2019.2.mw

I will submit some of these weaknesses in simplify as bug reports.