@mmcdara Yes, it really is wrong, because Tom used the claim (about surfdata's producing only 3D plots) to support the idea that -- in consequence -- they do not allow for legends.

The point is that only 2D plots can have legends, in the technical/built-in sense. 3D plots can have titles and captions, and those may be used as a kind of workaround for a legend, but without functionality to specify location. 3D plots don't allow for the legend plotting substructure.

@tomleslie Your claim about the result from a call to surfdata being a 3D plot is not true. The plots:-surfdata command can produce either a 3D surface plot or a 2D density-style plot.

And the calling sequence example that the OP provided in his Question shows the calling sequence for the 2D result.

Please provide your Matrix M, or full code to reproduce. That can be done using an uploaded and attached worksheet (green up-arrow in the Mapleprimes editor).

Also, you should state explicitly what you want.

One possibility is a "colorbar", ie. a thin bar with smoothly shaded gradient, normally displayed above or beside the plot. That's possible, but tricky if you want the whole assembly arbitrarily sized or if you want to be able to export it as a single image.

An easier possibility is a discrete number of shaded items (lines or thicker bars, corresponding to discrete heights or contours) displayed using the usual legend mechanism. If that's what you want then how many such items do you want? Do you want a fixed number, just for your fixed example with its particular kind of colorscheme? Or do you want re-usable and flexible code that can handle arbitrary numbers of such legend items for arbitrary coloring schemes?

The kernel (Maple engine) builtin arithmetic operators `+`, `*`, etc, are not units-aware. As far as they are concerned units are just some extra function calls which some expressions just happen to have as multiplicands.

Hence resolving and combining units can be done by Maple Library level commands. That's shown in my Answer's latter group of examples.

The Units:-Simple and Unit:-Standard packages can be "loaded", which rebinds various command names (including `+`, `*`, `/`, etc) with Library-level versions which are units-aware. These versions can resolve and combine units automatically. These were my Answer's first groups of examples. In my Answer I included URL references to the Help pages of those packages, so that you could read more about them.

@Felipe_123 

restart:

f:= proc(p,c) local j;
      Matrix([seq([0$j,
                   PolynomialTools:-CoefficientList(p,x)[],
                   0$(c-degree(p)-1-j)], j=0..c-degree(p)-1)]);
end proc:

f(x^4+3*x^3+x^2+2*x+1, 10);

f(x^5+11*x^2-3*x, 10);

@Pepini I see. Sorry, I misunderstood your wording.

What's your rationale for believing that an exact, explicit solution might be "seen" from the equations? I'm not seeing it (though my vision is poor).

I don't quite understand what's wrong with a numeric solution. Here a some ways:

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):

S1 := fsolve( {f(a)=f(a+ba), g(a)=g(a+ba)}, {a,ba}, {a=-2..1, ba = -2..1} );
          S1 := {a = 0.1089038833, ba = -1.784296181}

S1 := fsolve( {f(a)=f(a+ba), g(a)=g(a+ba)}, {a, ba=-2}, {a=-2..1} );
          S1 := {a = 0.1089038833, ba = -1.784296181}

S1 := fsolve( {f(a)=f(b), g(a)=g(b)}, {a, b=-2}, {a=-2..1} );
           S1 := {a = 0.1089038833, b = -1.675392298}

plots:-display(
   plot([f(t), g(t), t = -2 .. 1], color=red),
   plots:-pointplot([seq(eval([f(a),g(a)], pt), pt=[S1])],
                    symbol=solidcircle, symbolsize=12, color=blue),
   size=[300, 300]);

@mmcdara I've already responded to that query about animations having a common range/view in the other thread.

It's an ancient weakness in the interfaces's animation plot drivers -- various so-called global plotting options are rendered common to all frames, for these kind of traditional animation. (Explore offers an alternative, frame-by-frame behaviour when animating.)

If I recall correctly, other plotting options with a similar drawback include at least lightmodel, tickmarks, gridlines, orientation, size, scaling, labels, axes. I'll note that for orientation a workaround is to use viewpoint (despite some inaccurate statements in the Notes section of it documentation).

@mmcdara Since you asked, the GUI renders a "traditional" animation by examining all frames and utilizing the largest range (view) necessary to include the features from all (together). And so all frames are rendered using a common range/view. By "traditional" I mean animations created with plots:-animate or plots:-display(...,insequence).

In contrast, the Explore command creates (and the GUI renders) the frames 1-by-1 on demand, and the rendering range/view of each frame is determined individually. Sometimes that is a bonus, as a way to work around the forced behavior of the traditional animation. Sometimes people want the fixed, common range/view when using Explore, in which case it can be supplied to the plotting command. (See my previous Reply's attachment, in which there is a commented-out call to Explore and I added a forcing common view option to the matrixplot call. You could remove that view option, to see the effect of each frame's tallest column determining that frame's vertical view.)

@mmcdara I suspect that the OP is using Maple 18, in which the 1-argument calling sequence for the add command is not available.

Here are some adjustments, including add for older versions, and also your simpler plotting example for the Matrix powering from another thread:

re-markov_mmcdara_18.02_ac.mw

@mmcdara I was not looking for a "loophole" as much as a correction. I proposed Unit(1/s) for the OP's x (in exponent) since the OP's data already had Unit(s) attached. What ensued was evaluation in which the exponent is dimensionless.

@wswain The `eval` and the `=` loade from the Units:-Standard package was baulking at my attempt at substituion into the formula. And for Units:-Simple its loaded version of `=` was also complaining.

So I utilized the colon-minus prefix to access the original global versions, ie. :-eval and the prefix form :-`=` operator.

The global reference :-`=` cannot be used in the usual infix form, I supposed, so I used it in prefix form.

[edit] My comments about FPS are not central to the original problem you were having. It's more that I don't care for units-formatting, and mentioned FPS as an aside. Ease-of-use is fine, but it strikes me as a lurking, potential problem if something that displays in Unit(lbs) is actually in terms of Unit(kg/s)*Unit(s) in actual value. I'd rather combine units programmatically, and have the display match the actual values. Your mileage may vary.

@srikantha087 Yes. It can even be done without recomputation -- by which I mean that you only need compute the Matrix (or the surface from the procedure) once. You don't have to also do a further recomputation with, say, densityplot.

You can do it using the Matrix of precomputed data, or using a procedure (such as a dsolve solution) which computes on demand for x-y pairs.

And you in this way you can also ensure that the coloring scheme of the shaded plane is the same as for the surface. (That can also be attained using densityplot, but it's inefficient to do further computations if not necessary.)

Also, I find surfdata more flexible and powerful than, say, listdensityplot, where applicable.

surf_and_dens.mw

The first of these is from an 11x11 Matrix, and the second from a procedure using default grid option. As shown earlier, you can specify alternative axes' ranges (without having to force tickmarks).

If you really want contour lines added to that shaded plane (in addition to color, and after gridlines are removed by adding style=surface) then you could also include a contourplot result. Note that involves some futher computation.

Yest another finesse might be to utilize Interpolation on some precomputed Matrix data, to obtain a new procedure which can quickly compute interpolated heights for arbitrary x-y pairs upon demand.

If you need more then you should provide more (adequate) detail about precisely when you want to construct, and from what sources, eg. from Matrix, or from procedure, etc.

Note that contoutplot and densityplot/surfdata produce similar -- but actually different -- things. With contourplot you can get a finite number of colored contour lines or banded filled color strips, while with densityplot/surfdata you can get smoothly colored gradients (interpolated coloring). So when you write "contour plot (density)" it's not clear which you mean.

@vs140580 I suggest that you don't attempt the computations where evalf is only applied after the Eigenvalues call.

Try only the latter pair, where evalf is applied to the Matrices before calling Eigenvalues.

Presumably you've already checked that just the calls AdjacencyMatrix(g) and AllPairsDistance(g) themselves are not stalling?!. Those computations -- alone -- would be the first things I'd check.

@srikantha087 I am not sure whether using columns, like a histogram, is your specific goal. Perhaps it is.

But if you wanted to render a surface instead, note that the surfdata command allows you to speciy the axes' ranges through very simple options. Eg,

plots:-surfdata(M, 0..0.6, 0..0.6,
                colorscheme = ["Blue", "Green", "Yellow", "Red"],
                axes=normal, labels=[x,y,"f(x,y)"], orientation=[-125,70]);

That is easier than using maptrixplot (without heights=histogram) and manually creating tickmarks formulaically.

@Felipe_123 Yes, that is both simple and terse.

If you like saving keystrokes then even in old Maple 17.02 you could use the elementwise syntax,

(expand@`*`@op)~(a1);