@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?

@AHSAN Your question asked about a 3D plot, with some like a legend inside some blank space (eg. within the axes).

This image you just added above is not like what you asked, at all.

You should state clearly and precisely what you want  when you first ask your Questions.

@tomleslie The OP's equation was given as,

   64/19683*t^9 - 16/729*t^7 = (-t + sqrt(t^2 - 4))/2

which is equivalent to your expr2 (though you happen to have the radical isolated on the rhs). You squared both sides of your expr2, and expanded, to obtain expr3. But not all real roots of expr3 are actually roots of expr2. In particular the approximate root 2.1213203436 of your expr3 (or your expr4) is not a root of your expr2 or of the OP's equation.

The only real root of the OP's equation that is greater than 2 is given by the approximation 2.5579901741.

Also, if only real roots are wanted then there's little point to supplying the complex option to fsolve, only to have to further select the purely real roots from those.

I understand the appeal of creating your expr4, since as a univariate polynomial fsolve will find all roots for it, automatically. But the roots of your expr4 would need to be each checked for validity as roots of your expr2.

If the OP's equation is assigned to eqn then the fact that it has only a single real root greater than 2 can also be gauged by,

fsolve(eqn, t = 2 .. infinity);
fsolve(eqn, t = 2 .. infinity, avoid = {t = %});

@grheppler The first link in the Answer above starts off with this bullet-point for OSX,

I put the emphasis on that word Preferences, to distinguish it from the word Options.

@TechnicalSupport You're suggesting the calling sequence for plotting two scalar expressions (resulting in two curves). It seems clear that that is not at all what the OP means.

The OP has used the syntax for plotting a single curve, using the parametric calling sequence. It seems clear that the OP understands this and is choosing this deliberately.

That calling parametric sequence does not (yet, Maple 2021.1) support units. That's the OP's problem and complaint.

@Jean-Claude Arbaut This multiplication crash for member vv likely has nothing to do with CUDA. And the CUDA dgemm should not be used by default for MatrixMatrixMultiply or by `.` or `^`.

I really don't recommend that anyone load the CUDA package anymore. Its supported BLAS functions are mostly slower that the in-memory MKL equivalents on modern machines. If it doesn't serve as a workaround for this example of a dgemm crash then there's no benefit in using it.

The userinfo for LinearAlgebra still shows NAG names, but for all the functions under discussion in this thread the NAG external functions were replaced by Intel MKL equivalents by Maple 18. So I suspect that what's key here is some platform specific behaviour of the MKL dgemm bundled with Maple 2021.

It's useful to know that the multiplication example also crashes for the OP. But it's unfortunate, and surprising, to see a dgemm problem. (Upon my initial reading of this Question I'd expected a problem with the MKL svd function, which has been off-and-on and and occasionally problematic for very large matrices in some lapack & MKL minor releases. And for that routine there is a long-winded workaround to force an older "generic" lapack version of the function. So it's unusual and noteworthy, if instead what we have here is a dgemm matrix-multiplication crash.)

It's usually helpful to try and narrow down the hardware architectecure or operating system specifics on which the crash occurs. Eg, no problem on my i5-7400 running ubuntu 18.04.

I forget whether the following Maple call will work on MS-Windows:
     ssystem("processor full");
But if not then sharing the CPU chipset and OS information might help narrow it down.

Obviously there's no need for workarounds for anyone whose machine doesn't exhibit the problem. For someone who's machine has the problem, I'd be interested in knowing whether the following avoids the dgemm crash. The basic idea is to have the OS environment variable OMP_NUM_THREADS set to 1 in the shell that launches Maple. You'd know it worked if the Maple command,
   getenv(OMP_NUM_THREADS);
returned "1". By default the MKL external libraries intialization functions detect the number of usable cores, when that variable is unset. Setting it to 1 can disable MKL parallelism. For a 2500x2500 Matrix that will make the A^2 example run about 2-3 times slower in wall-clock real-rime on a quad-core machine. But it would be interesting and possibly useful if it prevented the crash.