If the name begins with an ampersand then the parser will accept its use as a binary infix function call (ie. allow its use as a binary infix operator).

For example,

restart;

`&A` := (a,b)->a^b:

x &A y;

               y
              x 

You don't have to assign anything to &A, to construct the call.

Also, you can also enter the call using prefix form, ie.  `&A`(x,y) , and by default that pretty-prints in the infix form.

The above doesn't allow you to enter your stated, literal example   x A y  as input, without the ampersand. However you can get some interesting effects for pretty-printed output and computation, by using the so-called extension mechanism of some low-level commands. Eg,

restart;
`print/&A` := proc(a,b) uses Typesetting;
                mrow(Typeset(a),
                     mi(" A ",':-fontweight'="bold"),
                     Typeset(b));
              end proc:
`expand/&A` := () -> A(args):
`value/&A` := () -> A(args):

A := (a,b) -> a^b:

foo := sin(x) &A sqrt(y);

expand(foo);
value(foo);

In order to alleviate burden on the GUI plot renderer the result of HeatMap is usually accomplished (internally) by use of a background image.

In Maple 2021.1 the background image is being incorrectly rendered to fill the whole inlined plotting window, instead of (as previously) filling only the area bounded by the axes. (My Maple 2021.0 for Linux does not seem to have the problem, so it might be new to point-release 2021.1.)

Two possible workarounds are (undocumented) forcing of the result as either a collection of polygons or a densityplot.

Those put more burden on the GUI, however (ie. they render more slowly, and can make the GUI response sluggish if the plot is swept-selected or right-click, and in some cases when the sheet is scrolled). Export to PNG format image seems reasonably sharp.

Statistics:-HeatMap(Matrix(128,(i,j)->modp(binomial(i,j),2)),
                    color=["White","Black"],method=polygons,
                    axis[1]=[location=high],axis[2]=[location=low],
                    size=[600,400]);

Statistics:-HeatMap(Matrix(128,(i,j)->1-modp(binomial(128-j+1,i),2)),
                    color=["white","Black"],
                    method=densityplot,style=surface,
                    axis[1]=[location=high,tickmarks=[seq(i=i,i=1..128)]],
                    axis[2]=[location=low,tickmarks=[seq(128-j+1=j,j=1..128)]],
                    axes=frame, size=[600,400]);

Here are some ideas, which might help you get started,

Shane_Kreller_M6_Maple_Assignment_ac.mw

Here is another way, using seq instead of a loop,

Given you initial list assigned to z,

LLq:=iquo(nops(z),26):
LLr:=irem(nops(z),26):
AZ:=parse~([$"A".."Z"]):
ans:=[seq(seq(`if`(i=1,AZ[j],cat(AZ[j],i-1))=z[26*(i-1)+j],j=1..26),i=1..LLq),
      seq(`if`(LLq=0,AZ[j],cat(AZ[j],LLq))=z[26*(LLq)+j],j=1..LLr)];

You might also create AZ with,

AZ:=convert~([$"A".."Z"],name):

Mapleprimes_Label_lists_ac.mw

Naturally, it's also possible to start the LHSs with A1..Z1, etc,

[seq(seq(cat(AZ[j], i) = z[26*(i-1)+j], j = 1 .. 26), i = 1 .. LLq),
 seq(cat(AZ[j], LLq+1) = z[26*LLq+j], j = 1 .. LLr)];

Here is one way to construct a 2D surfdata plot that has a legend.

The code is implemented as a procedure that accepts your original surfdata arguments, your simple colorscheme type (a simple list of colors), and also a few extra options to specify the number of legend items, legendstyle (location), etc.

It's a bit rough, but might serve your purpose. With a little effort I could make it more flexible.

Here is an example with data I made up (because you hadn't yet provided your data.) [edit] I correct an earlier mistake in which I accidentally reversed the color scheme.

surfdatalegend3.mw

And here is surfdata and a legend (with a few alternatives to look & feel) for your uploaded data:

surfdataLegend_ac.mw

If you want to add up a finite number of numeric quantities like that then you are often better off using add than sum.

With beta being a Vector you cannot evaluate the indexed reference beta[k] where k is (as yet) an unassigned name.

The sum command follows Maple's usual evaluation rules, in which arguments passed to procedures (here, sum) are evaluated up front. In contrast, the add command has special evaluation rules, which allow it to defer evaluation of the first argument until such time as the index name k takes on actual values.

RBF_Interpolation_ac.mw

If you do load not either the Units:-Simple or the Units:-Standard packages then the usual operators like `+`, `*`, etc, will not combine or merge units, or convert to base units (default is the SI system).

But even in that case that you have loaded neither of those systems you can still merge units through suitable use of either the combine or simplify commands.

restart;

with(Units:-Simple):

V1 := <6*Unit(mA)>:
V2 := <3*Unit(V)>:

res2 := V1 *~ V2;

                [ 9         ]
                [--- Unit(W)]
                [500        ]

restart;

with(Units:-Standard):

V1 := <6*Unit(mA)>:
V2 := <3*Unit(V)>:

V1 *~ V2;

                [ 9         ]
                [--- Unit(W)]
                [500        ]

restart;

V1 := <6*Unit(mA)>:
V2 := <3*Unit(V)>:

res1 := V1 *~ V2;

          res1 := [18 Unit(mA) Unit(V)]

combine(res1, units);

                [ 9         ]
                [--- Unit(W)]
                [500        ]

simplify(res1);

                [ 9         ]
                [--- Unit(W)]
                [500        ]

units_comb.mw

What's wrong with the call to solve that you mentioned?

restart;
kernelopts(version);
   Maple 2020.2, X86 64 LINUX, Nov 11 2020, Build ID 1502365

f := t -> exp(t) + exp(-t^2 - 2*t):
g := t -> exp(-t^2) + exp(-t^2 - 2*t):

tsols := [ solve(f(t)=g(t), t) ];

                tsols := [0, -1]

seq( [f(t),g(t)], t=tsols );

      [2, 2], [exp(-1) + exp(1), exp(-1) + exp(1)]

The problem is simply that plots:-animate always passes a float for the parameter n in the calling sequence that you've utilized. That conflicts with your syntax P^n.

It's easy enough to access it as trunc(n), for use as an integer. I suspect that is close to the shortest possible working change, for your original code (while retaining your original's default of 25 frames -- intentional by you, or not...).

restart;
WM := P -> n -> plots:-matrixplot(P^trunc(n), heights=histogram):

U := Matrix(2$2, [0.8, 0.2, 0.4, 0.6]):

plots:-animate(WM(U), [n], n=1..2);

Another easy workaround is as follows, which can be handy if parameter name n appears in multiple places within, say, WM(U). The following works with your original WM procedure, ie. I've moved the trunc into the specified arguments. Like your original this too would have default of 25 fames.

WM := P -> n -> plots:-matrixplot(P^n, heights=histogram):

plots:-animate(WM(U), ['trunc'(n)], n=1..2); # works ok

Notice that plots:-animate passes along a float for the parameter even in the case that the value of the supplied frames option aligns exactly with a specified integer range (which was your choice of calling sequence). Eg,

plots:-animate(WM(U), [n], n=1..2, frames=2); # produces an error

plots:-animate(WM(U), ['trunc'(n)], n=1..2, frames=2); # works ok

Your original attempt produces more than 2 frames, since the default for plots:-animate is 25 frames when passing a range for the parameter. If you really want only 2 frames from the range 1..2 then you can get by much more simply with just this (and your original WM),

plots:-animate(WM(U), [n], n=[$1..2]);

As Kitonum's code show, that alternate choice of calling sequence (passing a list of explicit integers instead of an implicit range) also allows for slowing the play rate (alas, inefficiently) through duplication.

Note: It seems reasonable to suppose that you are only looking for positive integer powers of a Matrix, judging by the similarity between this example and your responses in another Question thread. [edit] That is why I have not bothered to mention retaining the float usage and utilizing MatrixPower or similar.

[edit] I've only addressed the root cause of your example's issue with animate, because it seems like that was the puzzle for you here. I am sure that you are already aware of aspects like diagonalization, memoization, etc, that relate to efficiency of repeated Matrix powering.

There are these two mistakes:

1) You've used geom3d[point] but also loaded plottools. So that evaluates using the export point from plottools, which goes awry. Intead, utilize it as geom3d[:-point] or geom3d:-point.

2) There is an intended comment in ElloidInTet which does not begin with a # hash symbol, and so gets parsed as a product for the lhs of the intended next assignment statement. The intended comment contains the word "in", which is where the error arises.

Strange_Error_ac.mw

Your worksheet is a little weird in that it has a call to ElloidInTet occurring before the later definition of that procedure. But with the two mistakes (mentioned above) corrected then it runs OK for me if executed out-of-order.

Perhaps what you are after involves using Unit(1/s) for the x in your fitted formula. That way the seconds unit in Weight_time entries will cancel, and the result will have mass units (as do the entries of Pull_Weight). Eg,

   1.86*7.03^(x*Unit(1/('s')))*Unit('kg')

The Standard and Simple units environments get in the way, a little, for that. But below it one way (for each):

Maple_Primes_Question-worksheet_Units_ac_Standard.mw
Maple_Primes_Question-worksheet_Units_ac_Simple.mw

It seems somewhat over-complicated (and error prone?) to utilize the SI system and have unit-formatting for output make it all display with FPS. How about using the FPS system for the computations? That way you need't have to enter kg instead of lb, every now and then. Just a thought...
Maple_Primes_Question-worksheet_Units_ac_Simple_FPS.mw

In Maple 2020.2 (which the OP cites in one of his older Questions) it does not stall.

Essentially the same results are obtained much faster (a few milliseconds intsead of 0.25 seconds) by applying evalf to the Matrix before computing the Eigenvalues.

eig_add.mw

Here's one way (amongst several possible) to get that string s from k in Maple 17.02,

k := 5;

             5

s := convert(cat($0..k-1),string);

          "01234"

How much does efficiency matter to you, for that subsequent Vector generation? What other similar examples are you planning on treating? That subsequent, longer call (using StringTools commands) is not most efficient for the given example, though it's not clear what might be your general case.

restart;

kernelopts(version);

   Maple 17.02, X86 64 LINUX, Sep 5 2013, Build ID 872941

a := {x+1, x+2, x^2+1, x^2+x+2}:

a1 := combinat:-choose(a, 3):

map(`*`@op, a1);

     /                / 2    \                  / 2        \  
    { (x + 1) (x + 2) \x  + 1/, (x + 1) (x + 2) \x  + x + 2/, 
     \                                                        

              / 2    \ / 2        \          / 2    \ / 2        \\ 
      (x + 1) \x  + 1/ \x  + x + 2/, (x + 2) \x  + 1/ \x  + x + 2/ }
                                                                  /

In the calling sequence you're attempting last, the "objective procedure" utililized within the fdiff calls should accept two scalar arguments rather than a single 2-Vector.

Continuing your example,

f := (a,b) -> obj(<a,b>):

objgrad := proc(v::Vector, w::Vector)
        w[1] := fdiff(f, [1], [v[1],v[2]]);
        w[2] := fdiff(f, [2], [v[1],v[2]]);
        NULL;
end proc:

NLPSolve(2, obj, objectivegradient=objgrad);

                [                      [0.0364560120817733]]
                [0.276597509679878450, [                  ]]
                [                      [0.603788442821000 ]]

mmcdara_Opt_fdiff_grad.mw

(You could also construct scalar-argument procedure f first, and then construct your procedure obj to call that f. I believe that's how I did it in this old Post.)