@Carl Love Right, one subsindets call can clearly do both steps. Thanks. (My mind was on whether I could do much better than the freeze/thaw to avoid the infinite recursion, rather than how I delivered it...)

The OP hasn't yet explicitly asked why the endless loop occurred for him. I expect it's just that he was seeing the applyrule or subsindets action being re-applied to the new xi^k instances in the inserted H(k)*xi^k expressions, over and over.

I tried to make it fun by having my subsindets approach bypass the recursion using freeze, while my applyrule approach used the dummy __P.

It's still not entirely clear to me whether the OP wants an original xi=xi^1 and xi^(-1) handled, etc.

@vv You could get by with,

   <seq(`<|>`(seq(M[i])),i=1..2)>

@C_R You may have misunderstood me. I was not suggesting that you use a projected map of the Earth as image, or anything else as large, complicated, or hard to find as that.

I just intended this suggestion as a quick and easy way to get going with testing of a variety of pre-made, low-resolution patterns.

For example one could quickly use the Read and Scale commands of the ImageTools package, combined with the image option of the plot3d command. That Read command works with a URL for the string/name, so pattern images from the web may be tried.

Once you find a simple pattern that's effective for your task you might write the Maple code that produces it (or something akin to it).

@RezaZanjirani I can, but not for a few days.

@nm I don't understand why you chose your initial example, as opposed to your followup example.

@Zeineb You haven't explained what you're trying to accomplish.

The code is somewhat murky to me; I don't understand how you're intending to use the names t and x.

You also haven't told us what exact results you're expecting.

Are you perhaps looking for something like this?

Download compute_integral_1_ac.mw

@sursumCorda There is no super-special syntax for pairing multiple rules and transformations, but such a thing may be accomplished in a straightforward manner, although it may involve duplicate coding of the types.

The indets family of commands use Maple types for the second argument. There is a Help-page for building up structured (compound) types. I'm sure that you already know that {...} and Or(...) can be used to specify alternate types.

But you also want multiple conversions.

The third argument to subsindets/evalindets can be any custom procedure you want. It could be an appliable module. It should be able to involve overload. Such customization can distinguish between multiple types (in whatever heirarchy you want), and dispatch accordingly, in several different ways. You might need to duplicate the alternate types from the second argument in the dispatch mechanism.

Could you give some concrete examples? Perhaps something you might not be surprised as being medium-hard to emulate?

@dharr One of the difficulties here is the expansion, which can be undesirable -- possibly only because unnecessary, but also because it can increase the leaf-count.

With a very slightly different example, the expansion due to calling numer or denom can produce a result that is not best. (This is part of why I mentioned expand in my comment to the Question.)

Download cancel_ex1.mw

The idea of simplifying an equation in this way is not a bad idea.

But it shouldn't be done using that code snippet, which I wrote specifically for the example containing exp calls in the link you gave. I would write a more general (or targeted) version in quite a different manner, especially with regard to expand.

A reasonable place to start is to figure out what domain you want to handle, if only as a beginning. How about rational polynomials?

[edit] Regarding your code mentioned in your Question's Update, I'd mention expansion. The following expansion happens, for an example only slightly different:

But IMO that numerator on the lhs would be better if it had stayed as the more compact (y-2*x)^3+x.

I fully realize that this difficulty of expansion due to numer & denom is not directly part of your cross-cancellation task. But it's an unpleasant side-effect that's too common in Maple "simplification". It keeps me awake at night. I'd suggest that a simplification enhancement focusing on numerator&denominator cancellations should try and avoid it.

[note: this is in response to a Reply that might since have been moved or deleted.]

@sursumCorda One of my issues with applyrule is that it is idiosyncratic. Another is that it has more weaknesses and bugs than I'd like to see.

The applyrule command attempts to provide an easy and convenient syntax, but ends up with some awkward holes at important corner cases.

Maple is not built up with pattern matching as a fundamental brick. But Maple is built up in important ways upon its powerful and flexible type system. And the indets/subsindets/evalindets commands are designed to be used directly with that type system.

Moreover, the convenience of having indets work with the same "specifier" as subsindets provides a very handy and direct probe.

Of course, there will always be examples (even some short examples) where one approach beats the other for simplicity and terseness. But that's like anecdotal evidence, and is not any indicator of general power, robustness, or flexibility.

In my opinion there are more severe bugs and weakness in applyrule than in the type system. Unless I have a very restricted and special case I almost always reach for the subsindets group before applyrule.

But I do not want this Answer to become any longer conversation of the relative merits, details, or equivalences of these two approaches. Anyone who wants to start that discussion elsewhere is free to do so...

@RezaZanjirani You haven't explained what you want to happen when one of the functions does not return a numeric result while one or two of the other do return such. That's not covered by any of your (i), (ii), or (iii).

How close can the results be from two of your functions, for you to accept them as equivalent (or both the greatest) at a given point?

It's not clear to me what you mean by a "labeled" region. Do you mean you want separate colors for the shared cases? And, labeled via a legend entry or by textplot?

You wrote that plots:-inequal took too long. How long is acceptable for any given individual plot here? 30sec? 1min?

How smooth do you want the edges? How much extra time are you willing to wait for that?

Have you still not considered investigating rewriting your procedures so that they might be more efficient, even after making quite a few postings on this topic?

Your FirmModelPP procedure lacks option remember, which the other two procedures have it. Is there some reason not to have it?

What do you want to happen when any of the three functions is not defined at some point [alpha,delta]? Do you want that left blank, or colored by whichever of the other functions (which might be defined there) is greatest?

What do you want the coloring to be for some point [alpha,delta] when more than one of the three functions shares the greatest value?

ps. Re-executing your attached worksheet didn't produce the same 2nd plot for me as is saved as output in the file.

You might read the Description section on the Help-page for the root command, as well as that of the surd command.