@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);

@lekcha The (conditional check) inquality comparison of fs and tol requires that a value of type numeric is used for fs.

So,
  fs := evalf(f(x0));
suffices.

lekcha_1.mw

The result you claim for Matlab contains floats, and the result obtained in Maple does not, so they are clearly not the same expression.

@tomleslie My point is that the issue -- including the flaw you mention -- was already mentioned, and discussed in some detail, in at least two separate previous Question threads. It doesn't serve well to have yet another duplicate Question thread on the topic.

There's another closely related duplicated topic which also has at least its own three additional Question threads started by the OP, in the past few weeks. Most of it relates to pattern-matching, and the OP's continuing expectation that Maple's type system work in a fundamentally different manner.

Unfortunately the OP has (so far) not delineated the requirements of any underlying patter-matching problem class, to the extent that a robust or comprehensive approach can be easily formulated.

@lekcha I'm out of town for a few days, but if nobody else has answered then I'll get to this when I return.

As Joe points out in his answer, what's really going on in the OP's example relates to use of type `*`, and the fact the braces {..} denote type disjunction in the manner of Or(..). The OP has mistaken the problem with this example as being about type identical. And followup comments and replies below show that the goal is actually the same topic as several of the OP's recent Question threads.

These very same ordering issues with type `&*`, and the distinctions between it and and type `*`, were already covered in at two previous Question threads made by the same person within the past few weeks.

It was previously explained to the OP that this kind of use of type '`*`'({...}) does not test a specific number of multiplicands in a product (or guarantee each is present!). See the OP's Question of July 8th, What exactly is the difference between `&` and `&*`?.

And it was explained that type `&*` can guarantee existence and number of the specified multiplicands,  but not order. And one alternative structured check against a product was suggested, which could allow unspecified order through use of andmap and membertype. (Other alternative but related queries and predicates are also possible.) See OP's Question of July 1st, how to make type selection orderless.

It's not productive to have this topic of discussion duplicated and spread across multiple Question threads.

@tomleslie This is a correct answer.

@mmcdara This a relatively longwinded and inefficient way to accomplish a simple task.

I'm sorry, but it should be mentioned, because users should not be encouraged to utilize set results (eg. from fsolve or solve, etc) in this way.

@AHSAN You don't seem to understand. Your explanation is incomplete.

What do the colors and gridlines mean, in your latest image?

How do the few fixed pairs of values for two parameters beta and lambda figure into anything like a image with a continuous gradation of color?

There is no point in merely repeating the same inadequate explanation and image. That's not very respectful. You have to explain in detail the precise connection between your mutivariate expression and the plot you want.

I am finished here. 

@AHSAN I am waiting for you to provide a proper description of your goal.

As far as I can see your latest description and image, have little (if anything) to do with your original Question and  attachment (which needed only a few corrections).

I think that guessing what exactly you might want is unproductive.

@J F Ogilvie For what magnitude of relative accuracy are you looking?