@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.

@The function If you use the Calculus1:-Roots command, and only need float results, then it will be much more efficient to pass that command its numeric option. Internally this uses a scheme of recursively calling fsolve on subintervals between found roots.

If you go for the fsolve(...,maxsols=n) approach then note the following. This approach internally uses RootFinding:-NextZero in a loop. It also uses that command's maxdistance option (based on the last found root, and the specified range's upper end-point) to help limit how far it needs scan. The finite value of n prevents a runaway computation, in the more general case in which a finite range might contain infinitely many roots. Beware there is unfortunately a hard-coded 100-root limit (to this loop, under fsolve, and thus to the number of roots found). You can get rid of that limit by the following code (executed once per session, say in a startup region or initialization file).

Download fsolve_scalarmultiple_maxtries.mw

Note also that there are some kinds of expression that NextZero cannot handle. Some of those relate to possible discontinuities.

@superbee Perhaps you have accidentally toggled off the Editable checkbox that appears in the Status Bar? See also here.

If you cannot see the Maple GUI's Status Bar then you can enable that with the main menubar's choice:  View -> Status Bar

Someone keeps removing the tags associated with the Question. Please stop doing that.

@rupsagar Your question about collecting trig terms is different from this question about expanding trig calls, and would be better placed in its own Question thread.

You can use the collect command to group coefficients of trig terms.

For example,

Download collect_sincos_multiples.mw

Please stop submitting duplicate Question threads for this.

Please put your followups in this thread, instead.