@acer The ability to use those operators infix is as you say, but the precedence wasn't correctly set until 2020. I think that that may have been at my request.

@DJJerome1976 Okay, go to menu Tools => Options => Display. Select "Maple Notation" in the first box. Click "Apply Globally" or "Apply to Session" (doesn't matter). Now press Command-J. If things go as I hope, that pull-down box on the context bar should say "Maple Input". If it does, proceed with the copy and paste, and you should be good to go; if it doesn't, tell me what it does say.

Please respond as soon as possible!

@DJJerome1976 It's a bother simply that you or anyone uses 2D Input at all. It is by far the shoddiest piece of commercial scientific software that I've ever seen in my 42 years of using scientific software. I'm on the verge of totally refusing to help anyone who uses it.

Describe to me exactly what happens on your screen when you press Command-J: 

• Where is your cursor? Is it blinking?
• What is to the left of your cursor? What color is the thing to the left of your cursor?
• Describe the first three items on your context-sensitive toolbar (the bottom-most of the toolbars). In particular, what does it say in the first pull-down box on that toolbar?

Please respond as quickly as possible.

@acer In Maple 2020 1D input, all the inert % operators can be used infix, and they all have the same precedence as their non-inert "parent". So,

eq:= A %. X  = b;

@DJJerome1976 My code is already 1D input; it doesn't need to be converted to 1D input. To enter it as 1D input, press Ctrl-J to get a 1D input prompt (which looks like > ). Then copy and paste my code directly from the Answer and Replies above (do not recopy the now-corrupted 2D Input). That's all there is to it.

@DJJerome1976 None of syntax features added in Maple 2018 and 2019 (which are really really great features by the way) work in 2D Input. The features that I used above that won't work are embedded assignments, embedded local declarations, embedded do loops, arrow procedures with local variables, and the updating assignment operators minus=, ++, and --. 2D Input doesn't even recognize these as things that haven't been implemented yet; it simply perceives your input as total nonsense.

@mmcdara I disagree totally. You could just as well say that it's impossible to have a random poker hand because the cards are necessarily all different.

However, the OP should learn that when it's said without any qualification, "randomly chosen" means "randomly chosen with replacement", this being not their first Question whose Answer needed to be modified because of that. Perhaps this is all that you were trying to point out.

@jalal Since you've named the columns x[i] and n[i], you need to refer to them by those names in the Remove command:

Remove(df, x[i]);

The code for the inverse procedure is simpler:

PruferToTree:= proc(a::And(list(posint), satisfies(a-> max(a) < nops(a)+3)))
option `Author: Carl Love <carl.j.love@gmail.com> 2020-Nov-8`;
local d:= Array(1..nops(a)+2, ':-fill'= 1), i, j;
    for i in a do d[i]++ od;
    GraphTheory:-Graph(
        {for i in a do for j do if d[j]=1 then d[i]--; d[j]--; {i,j}; break fi od od}
        union
        {{seq}(ArrayTools:-SearchArray(d))}
    )
end proc
#This procedure is intended for 1D input only.
:
GT:-DrawGraph(PruferToTree([4,3,4,8,8,9,4]));

That's easily seen to be the same tree that we started with.

I tested the above code on random trees of up to 2^16 = 65,536 vertices. (A 2^16 tree takes about 10 seconds.) I concluded that the code is efficient, and that it achieves the theoretically optimal asymptotic time complexity O(n*ln(n)), where n is the number of vertices. Here are the details of my test:

For each k from 2 to 16, I generated 9 random trees of size n:= 2^k and added the CPU times for running my code on all 9. I divided this sum by ln(n) and called this AdjTime (adjusted time). Then I did a linear regression of ln(AdjTime) vs. ln(n), achieving a very high r^2 and very low p-values, which indicates that time/ln(n) is proportional to n, i.e., time ~ O(n*ln(n)).

Ns:= 2^~[$2..16]:
AdjTimes:= [seq](
    add(
        CodeTools:-Usage(
            TreeToPrufer(GT:-RandomGraphs:-RandomTree(n)), 
            output= cputime, quiet
        ),
        1..9
    ) / evalf(ln(n)),
    n= Ns
);
 AdjTimes := [0.01082021281, 0., 0.005770780164, 0.008944709253, 
   0.01130111115, 0.01607574474, 0.03390333346, 0.06251678511, 
   0.1308524402, 0.3564768292, 0.5353600847, 1.167029311, 
   2.278324618, 4.803020329, 9.783275745]

s:= 1+max(0, ListTools:-SearchAll(0., AdjTimes));
                             s := 3

Statistics:-LinearFit(
    [1,m], ln~(Ns[s..]), ln~(AdjTimes[s..]), m, 
    output= rsquared, summarize
);
Summary:
----------------
Model: -8.2575900+.93048285*m
----------------
Coefficients:
              Estimate  Std. Error  t-value  P(>|t|)
Parameter 1   -8.2576    0.2227     -37.0855   0.0000
Parameter 2    0.9305    0.0301      30.9269   0.0000
----------------
R-squared: 0.9886, Adjusted R-squared: 0.9876
                       0.988630192645212

@Jaqr I don't think that you actually mean "useless" as that word is used in common English. It has a negative or perjorative connotation that primpart doesn't deserve. Appropriate words are "unnecessary" or "superfluous".

@dim____ 

Use

solve(30 = rhs(sol), t); evalf(%);

... And the inertness effect of the `` symbols (as well as the invisible symbols themselves) can be removed by expand.

@Jaqr The command sign returns the sign of the "coefficient" of the "leading term" of the polynomial (those terms are in quotes because it's not absolutely clear (yet) that they are unambiguously defined). The mist-ery (mystery) arises because How does one determine which term is the leading term for a multivariate polynomial in the mist (midst) of the two categories of variables, some of which are primary and thus cannot appear in what will be called "coefficients"; and then how do you determine the sign of a coefficient that contains (non-primary) variables? Thankfully, sign returns an error rather than a misleading result if it cannot resolve the ambiguities. The way that your trick gets around this is that after the first primpart has discarded the "coefficients" (other than their signs), all remaining variables are considered primary for the computation of the sign, and thus the coefficients are numeric. Note that in this case it makes no difference to us which term is considered leading as long as for any p it's corresponding terms in both p and -p that are chosen (and that'll certainly happen because the coefficient has nothing to do with that determination).

I think that if my analysis above is completely correct, then the second primpart (the one on the left in your code, that being the one which is applied secondly) is unnecessary. Please check this.

@jalal Remove the randomize commands. This command, if it's ever used at all, should only be used once per restart.

Of course, random, by itself, does not imply different (or choice without replacement). If you want random choices without replacement, use combinat:-randperm:

Choices:= combinat:-randperm({indices(Plots, nolist)});