It is NOT a solution. Perhaps you mean that z0(t) = t^2*exp(-t) is a solution? This can be verified with odetest:

z0:= t-> t^2*exp(-t):
ode:= diff(z(t),t,t)+2*diff(z(t),t)+z(t)=2*exp(-t):
odetest(z(t)=z0(t), ode);
                               0

The return value 0 means that it's a solution.

According to its help, the 2nd argument to rgf_findrecur should be a list of 2*K consecutive terms of the sequence, where K is the order of the recurrence (as well as the 1st argument). Presumably, extra terms are simply ignored.

Edit: I replaced K with 2*K.

There's no point in using CodeTools:-Usage on some code that doesn't even work. To see that it doesn't work, remove the Usage command. The reason that Usage is obscuring that it doesn't work is because you've used output= bytesused, so the output is just that number rather than the result of your computation.

The vast majority of modules should not be packages. What benefit did you think you were getting by using option package? The only good reason (AFAIK) to use option package is if you want to load the module with with.

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.