There are several ways to go about this.

For example, you could obtain the result directly using the value command (or the active int command).

Or, if it's homework and you've been told to do it in a particular fashion, you could do it step by step. There too you have several choices about how to go about it. I'll give just one way, utilizing integration-by-parts, as illustration. (In this case I don't know what knowledge you have. If you do not see how integration-by-parts is working in each of the three calls below then please say so.)

Or, are you expected to express the formula for integration-by-parts, and then substitute for the various parts, exactly as if you were doing it by hand on paper?

I don't see limits of integration in your Question. Did you intend on supplying them?

Download example_byparts.mw

See the smartview option on the plot,options Help page

Download plot_view_problem_smartview.mw

Yes, it is a long-standing gripe that the GUI Table (inserted by the GUI when rendering arrays of plots) cannot be programmatically controlled and has suboptimal behavior.

You could try DocumentTools:-Tabulate instead, also making use of some of its additional functionality for controlling placement of the whole Table, dimensions, borders, etc.

I'd be interested in knowing how well its embedded Tables did upon export to PDF.

Here are two ways:

Download example_int_ac.mw

You could compile Jave code by doing an escaped shell command, (see ssystem). Depending on what is in it, you could run it with an external call (see define_external).

Did you want to map factor over the addends of eq? Note that elementwise factor~(expr) is not the same as map(factor,expr) if expr is a sum of terms rather than an indexable data structure.

Also, I don't understand from your description and attachment whether you are trying to operate (or not) on numerator and denominator separately.

Sorry, but I find your description unclear. What are your f(x) and g(x), etc?

Download example_ac.mw

I do not see the behavior that you describe, in Maple 2018.2, either in a Worksheet or a Document. In that version I see the plots rendered prior to final conclusion, separated in time by the Sleep() specification.

But I do see the behavior that you describe if I execute your code in a Document in Maple 18.02.

So I'll ask whether perhaps you have given this Question an incorrect Product label, and whether you might actually have an older version such as Maple 18 (released, 2014).

If you are in fact using Maple 18 then you can try your computation in a Worksheet, rather than a Document. See the main menubar's File->New->Worksheet to open a fresh Worksheet instead of a Document. In that environment I do indeed see the plots rendered prior to final conclusion, staggered in time by the Sleep() specification.

If you really want the staggered display within a Document in version Maple 18 or older then you could insert a Plot Component and push the plots into that instead or printing. That too would stagger the rendering with the loop iteration, but each of the plots would in turn overwrite the same location. Here is an example. I inserted the Plot Component using the Components palette.  Download loop_plot_EC.mw

By the way, if you ever use a version later than Maple 18 then you could get a similar (in-place) overwriting, staggered effect by using DocumentTools:-Tabluate([plot(...)]) instead of print(plot(...)) . Here is an example done in Maple 2015 .  loop_tab_2015.mw

Yes, there are several ways. You could try solve (possibly after evalf). You could try the addon DirectSearch package's SolveEquations command. You could try Optimization:-Minimize and use the equations for constraints. You might even be able to leverage fsolve (it depends).

Why not attach a worksheet and show us the system?

You didn't explain how you wanted to utilize "&", eg. with "tabular", "array", "align", etc. Note that Maple's latex command already emits "array" for a Matrix.

For "tabular", I found this in the vault, which could likely be adjusted as needed.

The last example produces this, for me, when processed using LaTeX.

Download latextabular.mw

This is a known issue with licensing.

You could try to install the last point-release update to Maple 2019.2.1 . That could help your case, to overcome a rare issue with licensing misidentification.

Otherwise you should contact Maplesoft Technical Support ( ie. send email to support@maplesoft.com )

If I add the compile=true option to the dsolve call then it takes about 6 seconds on my machine.

You supply the range option to dsolve; the first two odeplot calls over the same range are fast.

I suppress output of the eval calls to pick off the solution procedures.

I removed adaptive=8 in the final two plot calls, since it doesn't make sense to me to try adaptive plotting over such high oscillation (which would not be clearly seen at this resolution, I doubt). Instead I supply adaptive=false and force a high numpoints.

I used Maple 2019.2, as you had.

dsolve1_1r_ac0.mw

Do you want arrows? There are several available commands for that.

Plot_eigenvectors_in_3d_scatterplot_ac.mw

(I also changed the symbol to solidcircle. I gave Cov the symmetric shape.)

Using odeplot and a single dsolve (numeric) call -- with parameters -- this can be done somewhat efficiently.

(I compute it also with Carl's Answer's phaseportrait code, to illustrate that odeplot is reasonably quick. There's about a 10-fold timing speedup on my Maple 2020 on Linux, for this number of different Initial Conditions. The performance speedup increases with the number of ICs.)

Download polar_odeplot.mw

Here are two possible avenues ideas: 1) percent as a Unit, and 2) percent as an evalf'able constant. (I'll leave out the potential rabbit hole of some kind of object.)

2D Input mode seems to be a problem. And if that's the principle goal then this won't be worth much.

Note that in the Maple 2020 GUI the relevant output below renders OK for me, with an actual percent symbol even for the alternate. The Mapleprimes inline display doesn't seem to handle it, so a blank box appears below.

I could also have used the entity `%` for the Units variant. I used the so-called "Arabic Percent Symbol" only because it looked a little different. Both seem to be limited, and not work as 2D Input.

Download percent.mw

[edited] As far as I know, Units and evalf-extensions either do some inner manipulations with locals or rely upon global names. So I don't see offhand and attractive way to make either of these two mechanisms work with a top-level local % declaration.

For example, the following allows for easy 2D Input, but in order to get the final float value it also needs the convert to global (which makes it awkward to use).

Download percent_local_evalf.mw

The awkwardness might all be hidden behind an object, so that entry could be something easy like, say %() as an empty function call. And then the prettyprint could be made nice and clean, and a static evalf export could do the conversion via global, and regular prettyprint output could hide the function call brackets. Oof.

I notice that you cut down your y-range to 0.0..0.7 in your original 3D plot. If you had used the range y=0..1 then in your Maple 2018 there would be a ragged edge along one side of the surface.

For y>1/sqrt(2)=0.707... you can still get a decent rendering of the surface or the contours.  See below, for the higher y-contour values. (Some of this is automatically better in Maple 2020, btw.)

You can also get a little tighter near to x=1, where you had used 0.99 for the upper edge. (This aspect is not fully better, automatically, in Maple 2020.0.)

The effect of those changes can also bring down the surface edge towards z=0 along boundaries, ie. a more faithful representation IMO.

For the 2D curves it's a little trickier to get tight up to the lower x-value (within x=0..1) for y-values less than 1/sqrt(2). One can fiddle with the lower plot range (eg. a conditional and a formula), but roundoff error makes even that tricky. Easier is to allow adaptive 2D plotting and higher numpoints handle it.

Also, you can raise the 2D curves up to their contour values, to include in a 3D plot, if you'd like.

You can also get a variant of that using the contourplot3d command (with axis relabelling). Note that with the parametric calling sequence you can rearrange which formulas get used for each coordinate, and that can be matched by corresponding axis relabelling and reorientation.

Download Contour_Plot_MaplePrimes_ac.mw