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

Try passing the option  style=surface  to the plot3d call in question.

(Or, if your Maple version is truly ancient,  style=patchnogrid ).

The visual effect that you are calling "grid" is sometimes referred to as a wireframe. Its resolution details (when present in the rendering) are affected by the choice of the grid option, yes. But whether it appears at all -- or not -- is controlled by the style option.

See the Help page with Topic  plot3d,options  for more detail on the possible values that can be used for the style option.

If you search this site then you can find previous questions with the same topic.

For example, here.

I found that recent item by looking at the questions with the phaseportrait tag. It was right at the top.

There are other ways to search the site. Entering the terms in this sites Search bar produces a collection.

You can use multiple initial-conditions with the DEplot command. There are examples on its Help page.

You could also use the odeplot command.

I'm sure that someone will be quite willing to do all your problems in full (even coursework questions). But perhaps you could also show how far you've gotten so far.

Is this something like the look you're going for? (You can adjust the style, transparency, etc). Q1_ac.mw

If you don't need the solid boundary of the leading side (that moves) then it's a great deal simpler to do. I just prefer this look. I find that too much transparency makes these kinds of rotations overly difficult to visualize (and poorly so).

restart;
Lift3D:=plottools[transform]((x,y,z)->[x,z+sqrt(6-(sqrt(x^2+y^2))),y]):
F:=plottools[transform]((x,y)->[x,y+sqrt(6-x),0])(plot(sqrt(4-r)-sqrt(6-r),r=0..4,
                                                   filled,transparency=0.0)):
P := A -> plots:-display(orientation=[-90,15,-160],
            Lift3D(plot3d([[r,theta,sqrt(4-r)-sqrt(6-r)]],
                   r=0..4, theta=0..A, coords=cylindrical, filled,
                   orientation=[-90,15,-160], lightmodel=light1,
                   grid=[40,max(2,ceil(evalf(49*A/(2*Pi))))],
                   scaling=constrained, axes=normal, style=patch)),
            `if`(A<6.28,[F,plottools[rotate](F,-A,[[0,0,0],[0,1,0]])][],NULL),
            labels=[x,y,z]):
plots[animate](P, [A], A=0..2*Pi, frames=17, paraminfo=false);

This may be similarly resource intensive as an animated use of 3D plots:-shadebetween (for a similar number of frames). I could probably improve it by ditching the filled option in the plot3d call (inside P), and using a grid=[...,2] cylinder instead. That's done pretty well before -- the cylinder shape can have varying height, to joint the two surfaces where they don't intersect within the desired domain. Let me know if memory/GUI performance is a huge issue.

Here is a revision, which works.

I put a few comments into the Action Code, to explain how the substitution (for n) in the formula can be done.

I did not otherwise change the algorithm. It could be done more efficiently. I left it in the spirit of your prior work.

Iterative_components_ac.mw

[Edit] This is better than my original example (which passed n=3.0 and while relevant was not the most precise as explanation). I re-instated this Answer as it was accidentally deleted by someone else.

restart;
Digits := 20:
eval( ((n+1.)/n)^(n+1.), n=3 );

         3.1604938271604938268

restart;
Digits := 20:
evalf( eval( ((n+1)/n)^(n+1), n=3 ) );

         3.1604938271604938272

The difference between seq and $ is one of evaluation. (See also `||` versus cat.)

By the way, in the construction of your a list there is a single call to procedure u, into the result of which are placed the ten different integer arguments. In the construction of your b list there are ten calls to procedure u (each of which applies evalf).

This is difficult to test properly and carefully because of the following:
1) So-called "plot persistance", where an Output region of the GUI retails details of some "global plotting options" unless the output is fully removed.
2) Some additonal ordering issue that is hard to pin down -- possibly GUI internal state.

Having said that... I believe that the problem might be overcome by forcing the order in which the ORIENTATION and PROJECTION substructures appear within the PLOT3D structure.

Execute the following within a completely new and blank Worksheet. Note the use of separate Execution Groups. proj_issue_2019.mw

restart;

# new Execution Group
redo := proc(P::specfunc(PLOT3D)) local s,r;
  (s,r):=:-selectremove(:-type,[op(P)],'specfunc({:-PROJECTION,:-ORIENTATION})');
  :-PLOT3D(r[],:-sort(s)[]);
end proc:

# new Execution Group
P1 := plot3d(x*y, x=0..10, y=0..10, grid=[2,2], projection = 0.2, orientation = [55, 75, 0]):
P1;

# new Execution Group
P2 := redo(P1):
P2;

# new Execution Group
op(P1);
op(P2);

For me, the forced reordering fixed the issue.

However, I found that with sufficient jiggery-pokery-editing-rerunning I could somehow fool the GUI into rendering the previously incorrect plot as OK, even though I was taking care about point 1) above. And I know what I'm doing. Hence I conclude that there is some additional weirdness in the GUI state that can also make it magically appear fixed for all Exec Groups (ie, point 2 above).

I am seeing the bug in Maple 2017.2 to 2020.0 on 64bit Linux. But it works properly in Maple 17.02, 18.02, 2015.2 and 2016.2, in which versions it does not make any difference in which order the substructures appear.

I have submitted a bug report (Software Change Request).

Finally, it appears to not be sufficient to simply switch the order in which the projection and orientation options are supplied to the plot3d command. Sometimes that works, and sometimes not -- but do not be deceived into thinking it is sufficient, because you may be fooled by points 1) and 2) above.

You could look at combinat:-nextcomb.

That allows you to process/walk the combinations one by one without generating them all up front. But it also allows you to choose the size of the set.

If you have an original set of N things which are not simply integers then you can apply the nextcomb command to produce the combinations of the ordinals. You can use that to index into the original set of things, to get the appropriate subsets.

restart;
with(combinat):

S := {a,b,c,d,e,f,g}:

N := nops(S);
                             N := 7

Q := firstcomb(N, 3);
                         Q := {1, 2, 3}
S[[Q[]]];
                           {a, b, c}

Q := nextcomb( Q, N );
                         Q := {1, 2, 4}
S[[Q[]]];
                           {a, b, d}

Q := nextcomb( Q, N );
                         Q := {1, 2, 5}
S[[Q[]]];
                           {a, b, e}

You could also look at the Iterator package (available in your Maple 2017), with which you may get improved performance (of the generator, rather than of what you do with the iterates, naturally). If the cost of what you compute with the iterates dwarfs the generator cost then you might as well use whichever you find more convenient.