ComPoly:= proc(g, h, x::name)
local c, k, d:= degree(h,x)/degree(g,x), f;
    if d::integer then
        f:= add(c[k]*x^k, k= 0..d);
        eval(f, solve(identity(subs(x= g, f)=h, x)))
    fi
end proc
: 
ComPoly((x+1)^2, 2*x^4+8*x^3+13*x^2+10*x+6, x);
                             2        
                          2 x  + x + 3

You can combine non-indexed subscripting with concatenation like this

add(1/x__||i, i= 1..5)

This won't work with sum because sum evaluates its arguments before supplying the index values.

I am not saying in this Answer anything fundamentally different than what @nm said. I'm just rephrasing it because your Reply to that Answer indicates that you don't understand yet.

Here's your call to CodeTools:-Usage:

Usage(SOL[n+1], output = ['cputime', 'output', 'bytesused'])

The first argument, SOL[n+1], should be a call to the procedure that you want to measure. But SOL[n+1] is obviously not a call to a procedure because it has no parentheses.

The exact same thing applies to your other Question (now deleted) about the low and constant memory numbers.

Footnote (just for nitpickers): Yes, I know that the 1st argument doesn't need to be a procedure call. I said that it should be. In this case, the OP has no good reason for it not to be.

Great Question. Vote up.

It can be done with a small "surgery" on the plot structure after it's created to change the floats back to their corresponding fractions. Assuming G is your graph, P is your plot structure, and all the weights were originally specified as explicit fractions (which is how you coded it), do this (there's no need to look at the plot first):

Fr:= table(
    sort([indets(P, And(string, float &under parse))[]]) =~
    sort([indets(GraphTheory:-WeightMatrix(G), fraction)[]])
):
subsindets[2](P, And(string, float &under parse), Fr, index);

Regarding your title on the usefulness of parse: If you take any syntactically correct expression e containing no local variables, put it in quotes, and then wrap it with parse, then the parse and quotes cancel each other, so you're just left with the original expression e (possibly in a not-fully-evaluated form). So, usually it's not useful to use parse and quotes together in this way, neither in textplot nor anywhere else.

Regarding the italicized 3 produced in the denominator of Kitonum's 2nd example: Replace the `3` in his command with `#mo(3)`, and it'll be printed as simply 3 in the normal upright font. This kind of command inside back quotes comes from MathML, and it's not documented in the Maple help (AFAIK). And, AFAIK, all such commands begin with #m. These commands all create Maple symbols (the simplest type of name), as is implied by the back quotes. The Maple kernel treats them like any other name. Their purpose is to create names which are prettyprinted in nonstandard ways by the GUI but are effectively inert to the kernel.

In addition to using piecewise, you should get rid of proc. It's only due to coincidence that Kitonum's code works. (The coincidence being that the procedure doesn't use its parameter H.)

restart;

nuhf:=0.294*10^(-6):
Rehf:=Vhf*H/nuhf:
Vhf:=0.5:
rhohf:=965.31:
Lhs:=2.5*10^(-3):
DP1:=f1*Lhs*rhohf*Vhf^2/(2*H):
f1:=4*18.3/Rehf:
Whs:=1:
mhf:=rhohf*Vhf*Whs*H:
Rehf:=Vhf*H/nuhf:
PL1:=DP1*mhf/rhohf:
DP2:=f2*Lhs*rhohf*Vhf^2/(2*H):
f2:=0.3164/(Rehf^(0.25)):
PL2:=DP2*mhf/rhohf:

procd:= 
piecewise(Rehf<1000, PL1, Rehf>1000, PL2); 

plot(procd, H= 0..0.002);

Yes, solve's result means that the equation is true for any x.

At some point you run into the physical limitations of the resolution of your display. Having too many computed points can conflict with that. At the moment, I'm reading this on my phone, which has a much higher resolution than most computer monitors, and I see no difference in the plots above; both look perfectly smooth. The resolution (as mentioned by mmcdara) option can help with this. Also check the "anti-aliasing" option from the Tools => Options menu.

See command CodeTools:-Profiling:-Profile (help page ?CodeTools,Profiling,Profile).

I wrote a detailed Answer about 2 - 3 months ago that showed details of using this command. I would post a link to that, except that I can't find it due to this site's horrible search functionality. I suspect that someone else here can likely find it and post that link.

Edit: Profile gives you a line-by-line breakdown of time and memory usage. If instead you just want the average time and memory usage per iteration, then Tom's suggestion of CodeTools:-Usage would be easier to use than Profile.

See the help pages for the packages Tolerances and ScientificErrorAnalysis.

Creating good-looking large-scale documents automatically with printf is nearly impossible. Creating them by hand from palettes is onerous and repetitious. Maple can generate Latex output; that may be the way to go. There are major improvements to Maple's Latex capability coming soon. There are discussions about Maple's Latex here nearly every day.

You can encode Greek letters (as well as thousands of other symbols, nearly every symbol used in every language and special field of study in the world) as Unicode (see Wikipedia article https://en.wikipedia.org/wiki/Unicode). The Unicode numbers for the Greek alphabet (or just about any alphabet) can be found on that alphabet's Wikipedia page. Below, I've encoded the Greek uppercase and lowercase alphabets:

Greek_uppers:= [
    "Alpha", "Beta", "Gamma", "Delta", "Epsilon", "Zeta", "Eta", 
    "Theta", "Iota", "Kappa", "Lambda", "Mu", "Nu", "Xi", "Omicron",
    "Pi", "Rho", "Sigma2", "Sigma", "Tau", "Upsilon", "Phi", "Chi",
    "Psi", "Omega"
]:
Greek_lowers:= StringTools:-LowerCase~(Greek_uppers):   
Greek:= table([
    (Greek_uppers =~ [$145..145+24])[],
    (Greek_lowers =~ [$145+32..145+32+24])[]
]):
Convert:= proc(x)
local r,q; 
    r:= irem(x, 64, q);
    cat(StringTools:-Char~([204+q, 128+r])[])
end proc
: 
Greek:= Convert~(Greek):

#To use it in printf, do, for example
printf("%d %s", 150, Greek["Omega"]);
150 Ω

Edit: The code above has been corrected to account for the two variations of lowercase sigma, as pointed out by acer. The character Greek["Sigma2"] is undefined as an uppercase character. It's only in the table to maintain the one-to-one correspondence between upper- and lowercase.

The code above uses "magic numbers" specific to the Unicode Greek alphabet. It wouldn't be difficult to write a version of Convert for any Unicode "point" (as they call them); I just haven't done so yet.

Yes, I often have this problem also, on either of my computers. I don't know what causes it, but once it happens, its effect spreads to all open worksheets. It affects numerous other symbols also, such as + (becomes C) and - (becomes K). This problem only affects the display of the expressions; the correct expressions are stored internally. To get the correct display, save the worksheet(s), close your entire Maple session, and start it again.

As you've noticed, there are many ways. There are numerous formats that can be used with printf, including modifiers that apply to rtables (i.e., Vectors, Matrixs, Arrays). Using these, the loops and seqs of the answers above can be replaced by a single-line command:

results:= <1,2,3,4>:
names:= <"resistor", "opamp", "name3", "name4">:

printf("%{}-*A", 1+max(length~(names)), <names | results>);
resistor  1        
opamp     2        
name3     3        
name4     4        

Here's what the format characters mean. Many of these are common to formatted print statements in numerous languages, some of them nearly twice as old as Maple.

1. % introduces a format specifier; anything else (not used here) is printed as a literal.
2. {} indicates that the format is to be applied to an entire rtable. This is not always needed, but it's needed for the A format.
3. - left justifies each item within its field.
4. * will be substituted with an integer that will be supplied in the data; in this case, the integer specifies the field width.
5. A is a generic format that handles numeric, symbolic, and string data, omitting quotes for strings.

And here's what the rest of the syntax means. These can be used anywhere in Maple, not just in printf.

1. 1+max(length~(names)) is the width specifier for point #4 in the previous section.
2. ~ is the elementwise operator, which in this case applies length to the elements of the vector rather than to the vector itself. Thus this expression is the maximum string length plus 1.
3. < ... | ... > is the columnwise juxtaposition of two rtables​​​​​​​. So, in this particular case, the result is a matrix constructed from the column vectors.

These things are documented on the following help pages (although it takes much practice to learn many of these):

• ?rtable_printf  ({})
• ?printf  (%, -, *, A)
• ?elementwise (~)
• ?LinearAlgebra,General,​​​​​​​MVshortcut (< ... | ... >).

To avoid possible confusion between mathematical vectors and what Maple calls a vector (there's significant overlap of those notions, but they're not identical), you can refer to them (for example, when posting questions) as "arrays". Kitonum's Answer treats your Question as if you meant a geometrical vector.

There are numerous mostly interchangeable (with the appropriate syntac) one-dimensional containers in Maple: sequences (seq(...),  ... $ ...), lists ([ ... ]), Vectors (Vector, < ... >), Arrays (Array), tables (table). Don't use the deprecated containers vector or array (note the lowercase distinction). Some of these can also be multidimensional, of course. Vectors, Arrrays, and Matrixs are collectively known as rtables, and they can also be constructed with the rtable command, often with a significant efficiency gain for the construction.

If you'd like to store the ​​​​​​​labels and values together, Maple offers numerous containers for that: Records, DataSeries, DataFrames, tables, and some more esoteric things. Some of these automatically display in a prettyprinted form that may be suitable for your needs; no need for any explicit print commands.

I have only read your code (by eye); I haven't executed it. In reading it, I spotted many suspicious things. I can't (by eye) say for certain that any of these are the source of your error, but many of them are things that often do lead to errors. They should all be corrected regardless of whether they caused the error. I've listed them in order from most likely to least likely to cause errors:

1. The use of both f and f[i] as assigned function names, and likewise for all the other function names and indices for which you've done this.
2. The use of sum instead of add.
3. Defining functions via the syntax f(x):= ... rather than f:= x-> .... (or, in most of your cases, unapply).
4. Inclusion of symbolic manipulations (such as simplify and rhs) in the body of a function. Such a function should be defined with unapply. 
5. The command ax:= ax should be removed entirely.
6. Replace 3.14 with Pi throughout.
7. After setting m:= .2, all subsequent .2 should be replaced by m.

All of these things are very easy to correct, so please do that before investigating your error any further. And, if we're lucky, this alone will correct the error. If it doesn't, post your modified code here.

There are two major issues that you need to correct:

1. Your functions f and g that numerically evaluate the derivatives should only evaluate the right-side expressions and not the derivatives themselves on the left sides of those equations. Indeed, the Runge-Kutta methods do not need explicit derivatives at all. This is the immediate cause of your error message.

2. You have a system of 2nd-order ODEs. Runge-Kutta methods require 1st-order ODEs. Any system of ODEs where each ODE has its highest-order derivative isolated on the left side of the equation and all of these highest-order derivatives are for different dependent variables (i.e., x(t), y(t)) is trivial to convert to a 1st-order system by the method described in the text that you show, specifically the sentence that begins "If the satellite's ...."