@sursumCorda What haven't you responded to my Answer below?

@nm Yes, your guess as to why the code returns 2 is correct. If the answer is supposed to be 1, then I'm sure that your concept of "degree" of a differential equation is worthless. So, I'm not wasting any more time on something that's worthless. What does your beloved Mathematica say about the degree of this ODE?

Recall this definition of degree of a differential equation that you gave on 2019-July-19:

• "In mathematics, the degree of a differential equation is the power of its highest derivative, after the equation has been made rational and integral in all of its derivatives"

What makes this equation different from the 2nd, 3rd, 5th, and 6th equations on your test list, for which you accept that the "degree" is 2?

Also consider your original Question:

"For an example, given 

restart;
ode:=(1+diff(y(x),x)^2)^(3/2)=diff(y(x),x$2)

I want the command to return 2 for the order of the ODE and degree is also 2 in this case."

What makes this new equation different from that?

@Ronan The scope of those variables must include both procedures ppp and Qprj. Therefore they muist be local to the outermost module, rt.

Can we see equations 20-25, which specify v_0(t), ..., v_5(t)?

@Anthrazit The first argument of XMLElement, the "a" in this case, is an identifier for the element itself and is not considered to be one of its children.

@PaulNewton You wrote:

• Thank you, but I must agree with acer 27088 said yesterday at 745 AM
  In comparison, using complicated regular expression matching looks needlessly complicated here.

If you already know that your string ends with the reference number (such as 2.13) in parentheses, then I agree that Drop - Take is easier. The point of the regular expression is to check whether the reference number is there, at the end. If it's not there, the Drop - Take will return whatever the last item in parentheses is, even if it's in the middle of the string. 

@Carl Love Consider these suggested improvements to your program:

is_prime:= proc(x::integer)
    if x < 2 then false
    elif x = 2 then true
    elif irem(x,2) = 0 then
        userinfo(1, is_prime, cat(``, x, ` is divisible by 2.`)); 
        false
    else
        local i, `i^2`:= 1;
        for i from 2 while (`i^2`+= 4*i++) <= x do
            if irem(x,i) = 0 then
                userinfo(1, is_prime, cat(``, x, ` is divisible by `, i, `.`));
                return false
            fi
        od;
        true
    fi
end proc:

infolevel[is_prime]:= 1:
is_prime(10^6+1);
is_prime: 1000001 is divisible by 101.
                             false
is_prime(10^6+3);
                              true

@sursumCorda Yes, you can usually run them. In this case, you certainly can. However, HamiltonianSAT is not a kernel function, but rather a local (rather than export) of module GraphTheory. To access module locals, you need to set

kernelopts(opaquemodules= false):

Then you can run, for example, 

GraphTheory:-HamiltonianSAT(G, true, true); #assuming G has been assigned a graph!

When accessing a module local this way, the module-name prefix, e.g., GraphTheory:-, is always needed, regardless of whether the module's package has been loaded with a with command.

@sursumCorda If you read the code with showstat(GraphTheory:-IsHamiltonian), I think that you'll understand what's going on. Information about a graph G can be stored in the graph's data structure with the command GraphTheory:-SetGraphAttribute and retrieved with GraphTheory:-GetGraphAttribute. Look for those commands in the code. It's simply remembering that it has already proven the graph is Hamiltonian. Some graphs from SpecialGraphs also have this information prestored. That's the case for your H3.

@MANUTTM Like this:

beta:= {$1..8}: 
plotdata:= Array(1..nops(K), 1..nops(beta), 1..12):
for j to nops(K) do
    k1:= K[j];
    for i to nops(beta) do 
        b:= beta[i]; 
        Etemp := eval(
            `πcentral`(p, e, z), 
            [A= 0, B= 2, alpha= 50, beta= b, c= 5, k= k1, mu= 10, v= 1]
        );
        Soln:= NLPSolve(Etemp, p= 5..500, e= 0.5..10, z= 0..10, maximize);
        (etemp, ptemp, ztemp):= eval([e, p, z], Soln[2])[]; 
        `πtemp` := Soln[1];
        y_temp:= eval(y(p,e), [alpha= 50, beta= b, p= ptemp, k= k1, e= etemp]);
        q_temp:= y_temp + ztemp;
        E_decent := eval(
            `πcentral`(p, e, z), 
            [A= 0, B= 2, alpha= 50, beta= b, c= 10, k= k1, mu= 10, v= 1]
        );
        Sol:= NLPSolve(E_decent, p= 5..500, e= 0.5..10, z= 0..10, maximize);
        (e_d, p_d, z_d):= eval([e, p, z], Sol[2])[];
        `π_rd`:= Sol[1];
        y_d:= eval(y(p,e), [alpha= 50, beta= b, p= p_d, k= k1, e= e_d]);
        q_d:= y_d + z_d;
       `πdmanf` := (w_d - c_d)*q_d;
       `π_d` := `π_rd` + `πdmanf`;
        plotdata[j,i] := < 
            b | ztemp | ptemp | etemp | q_temp | `&pi;temp` | 
            z_d | p_d | e_d | q_d | `&pi;_rd` | `&pi;dmanf`
        >
    od
od:
(DocumentTools:-Tabulate@DataFrame)(
    evalf[5](<seq(seq(plotdata[j,i,2..], j= 1..nops(K)), i= 1..nops(beta))>),
    rows= [seq](seq(cat(`&beta; = `, i, `, K = `, j), j= 1..nops(K)), i= 1..nops(beta)),
    columns= [
        ` ztemp`, ` ptemp`, ` etemp`, ` q_temp`, ` &pi;temp`,
        ` z_d`, ` p_d`, ` e_d`, ` q_d`, ` &pi;_rd`, ` &pi;manf`
    ]
):
plots:-display(
    <seq(
        plot(
            [seq](Matrix(plotdata[j, .., [1,jj]]), jj= 3..5), legend= ['p', 'e', 'q'],
            style= pointline, symbol= [box, diamond, solidcircle], 
            labels= ['beta', ``], title= sprintf("k1 = %a", K[j]), axes= boxed
        ),
        j= 1..nops(K)
    )>^%T
); 

@Carl Love Here is the patch (which only took 22 minutes to write): 

restart:
sav:= eval(GraphTheory:-IsHamiltonian):
unprotect(GraphTheory:-IsHamiltonian):
GraphTheory:-IsHamiltonian:= overload([
    proc(G::GRAPHLN, cycle::name:= (), {method::identical(tsp):= ':-tsp'})
    option overload;
    uses GT= GraphTheory;
    local d, C;
        try (d,C):= GT:-TravelingSalesman(G, GT:-AdjacencyMatrix(G))
        catch "%1 expects a connected": return false
        end try;
        if d = infinity then return false fi;
        if cycle::name then cycle:= C fi;
        true
    end proc,

    eval(sav)
]):
protect(GraphTheory:-IsHamiltonian):

#Test on your example:
GT:= GraphTheory:
GT:- IsHamiltonian(GT:-CompleteGraph(3,3), 'C', method= tsp);
                              true
C;
                     [1, 2, 4, 5, 6, 3, 1]

@PaulNewton 

Everything that I know about regular expressions came from reading the help pages
?StringTools,Regular_Expressions, ?StringTools,RegMatch, and ?StringTools,RegSubs, so they can't be that "dark".

Here's a procedure that omits the true:

NumberAtEnd:= proc(S::string)
description 
    "Extract a parenthesized number, possibly containing periods, from the end of a string"
;
local r; 
    if StringTools:-RegMatch("\\(([0-9.]*)\\)$", S, r$2) then r else FAIL fi
end proc
:
NumberAtEnd(L1);
                             "2.13"

@acer Thank you. I thought that you might have something in mind with a custom embedded component, not necessarily Explore.

You wrote:

• There are a few more tricks possible that can reduce kernel/Library side memory use here, eg. Aliases instead of temporary rtables for data passed to the plotting commands, direct construction of final PLOT structures, etc.

I thought that that was what my code did. Do you see it differently? The only usage of any plotting commands is in the construction of the first frame. The frame-changing procedure P only writes 3 numbers directly into the existing Frame without reconstructing it.

• But I doubt any of that would help with a GUI memory clog on an embedded Plot Component.

Correct. My measures substantially reduce the execution time, especially the startup, but don't help with the GUI memory problem. And it reduces the memory allocation required for the kernel, but that was already fairly small anyway.

Is there any way to insert ssystem calls (say, after every 100 frames) to invoke the Java garbage collector? 

@dharr Thanks for pointing that out. I didn't read the text closely enough. My Answer is thus irrelevant to this Question.

@mmcdara It turns out, in this case, that the slowness is caused entirely by the presence of sqrt(89) (which is the only radical in the matrix). Replacing this with a variable is all that's needed to get a quick result. A much-easier-to-read initial matrix and final result can be obtained by noting that D__pile and E__c can be factored out of every matrix entry.

CodeTools:-Usage(
    length((MP1:= 
        eval(
            LinearAlgebra:-MatrixInverse(
                eval(KGff, sqrt(89)= sqrt89), 
                method= pseudo
            ),
            sqrt89= sqrt(89)
        )
    ))
);
memory used=52.29MiB, alloc change=0 bytes,
cpu time=469.00ms, real time=481.00ms, gc time=0ns
                             10767
CodeTools:-Usage(
    length((MP2:= 
        eval(
            LinearAlgebra:-MatrixInverse(
                eval(KGff, [sqrt(89)= sqrt89, D__pile= 1, E__c= 1]),  
                method= pseudo
            ).(D__pile*E__c)^(-1),
            sqrt89= sqrt(89)
        )
    ))
);
memory used=19.46MiB, alloc change=0 bytes, 
cpu time=172.00ms, real time=178.00ms, gc time=0ns
                              4167