@maxbanados By "that whole family of commands", I mean applyrule, define, definemore, match, patmatch, and typematch. Maple's type subsystem has a very rich and highly logical syntax easily capable of expressing types of arbitrary complexity, with subtypes nested arbitrarily deep (even recursively). The commands listed above use a variation of a miniscule subset of that syntax. That variation is incredibly frustrating and illogical (and even sometimes self-contradictory) to me. The command compiletable also uses that variation; however, I didn't include it in "that family" because it has important functionality that'd be elsewise difficult to duplicate. Also, it appears to me (although I've only checked superficially) that there's been no significant update to these commands in over 20 years. I'd guess that whoever developed these moved on from Maple.

The premier command for extracting subexpressions based on their type is now (and always has been) indets.

Regarding integrals with external coefficients: If you can tell me how you want to handle these special cases, I can advise further:

1. 2*Int(...)*Int(...)
2. 2*x*Int(f(x), x) #indefinite
3. 2*x*Int(f(x), x= a..b) #definite
4. 2*Int(...) / Int(...)

Regarding deconstruction: Maple's type system is great, one of the really powerful parts of the language. However, often we can assume that an expression is syntactically correct (so, some other syntax checker has already done the type work). Then the deconstruction can use the simpler commands op, lhs, rhs, etc. Here's an example:

IntDecon:= proc(J::specfunc(Int))
local v:= op(2,J);   
    Record(
        "operator"::name= op(0,J),
        "integrand"::algebraic= op(1,J),
        "intvars"::list(name)= 
            `if`(v::list(name= range), lhs~(v), [v]),
        "lowerbounds"::list(algebraic)= 
            `if`(v::name, [], (lhs@rhs)~(`if`(v::list, v, [v]))),
        "upperbounds"::list(algebraic)=
            `if`(v::name, [], (rhs@@2)~(`if`(v::list, v, [v]))),
        "options"::list({name, name= anything})= [op](3.., J)
    )
end proc
:
I1:= Int(x*y, [x= -1..1, y= -2..2], numeric):
I1d:= IntDecon(I1);
I1d := Record(operator::name = Int, integrand::algebraic = x y, 
  intvars::(list(name)) = [x, y], 
  lowerbounds::(list(algebraic)) = [-1, -2], 
  upperbounds::(list(algebraic)) = [1, 2], 
  `options`::(list({name, name = anything})) = [numeric])

I1d:-intvars;
                             [x, y]

Regarding evalb and Categorize: No, I think that Categorize is a great command. And recall that the problem in your Question has nothing to do with typematch either! Please post that example.

@maxbanados The expressions X and X1 are not "identical". They may be mathematically equivalent (hopefully that's true), but the fact that they're not identical can be easily seen by comparing the first terms of the integrands. So, this is not a problem of typematch. I'd like to figure out why X and X1 aren't identical. So far, I know that it has something to do with the two different forms of inputting a double integral: Int(Int(..., x= ...), y= ...) and Int(..., [x= ..., y= ...]).

I would strongly discourage you from using typematch, patmatch, and that whole family of commands. I have absolutely no use for them. The fact that they rely on the order of the terms (as shown by this example) is part of why they're worthless. 

Also, you cannot rely on the prettyprinted display of an expression to reveal its internal structure. The command lprint is better for that. Compare lprint(X) and lprint(X1).

@Ivi You most definitely have not found the solution! Your 2 Replies prior to the most recent are mathematical nonsense. They express something which is trivial, and mathematically true, but which has nothing to do with solving your original problem. The right-sided derivative at t=0 is 5/2. If you'd like Maple to say that, we can work on that. There are only two reasonable answers to this Question, depending on how you define "derivative": undefined or 5/2.

undefined is a mathematically valid answer to many problems; it is not an error message.

@MapleEnthusiast You wrote:

• The domains for the parameters are as follows: For all pi, p, and gamma, we have pi, p, gamma∈[0,1], as well as epsilon>0.

Then it's hopeless because under those parameter ranges any of the denominators in rows 3 or 4 could be 0 or arbitrarily close to 0.

@vv You wrote:

• The Gershgorin theorem is too simple to hope for a proof. It is useless even to prove the result for standard stochastic matrices.

That's not true at all. For a standard stochastic matrix, the only possible Gershgorin circles have centers c in the interval [0,1] and radii 1-c. All such circles lie within the unit circle. This proves that the spectral radius is <= 1. On the other hand, it's obvious that 1 is an eigenvalue with the eigenvector being composed of all 1s. Thus, the spectral radius is 1.

My knowledge of quantum matters is rudimentary, so this Reply may be completely wacky, but aren't those discontinuities literally the "quantum leaps"?

You'll need to post a worksheet showing the two results. Use the green uparrow on the MaplePrimes editor's toolbar.

@acer You wrote:

• I see only mention of indexed names in the current version of the Question. Did the OP actually ever ask about "subscripted" names? Otherwise, I don't understand why Carl wrote at length here about so-called atomic, subscripted names versus indexed names.

The double-underscore syntax is relatively new (compared to the square-bracket syntax) and relatively unknown. I thought that there was a good chance that the OP was unaware of the distinction and unaware of the potential harm that could come from assigning to indexed names. And if they were unaware, I thought that there was a very good chance that they'd decide that using subscripted names would be better for their purpose. Note that unaware users making assignments to indexed names is a major source of problems reported here. Neither indexed nor subscripted names are explicitly mentioned (in those terms) in the Question. 

@Carl Love Further notes on the code in the Answer above:

1. The code originally had a line ModuleLoad() as the second-to-last line (I'm not referring to the ModuleLoad() that is the fourth-to-last line). This line did nothing, neither good nor bad, and I removed it. It was simply a leftover from a preliminary version of the code that I forgot to remove before posting.
2. The code originally had a line ModuleType::static:= ()-> true. This line could do something; however, I decided that what it did do was not a signifcant enough part of the educational purpose of this example, so I removed it.
3. The global keyword type name :-person_type and the local object-submodule name person_type are different names, just like any local/global pair whose names just happen to be spelled the same. It is simply by convention that the primary type associated with an object-module has a name spelled the same as the object class itself. The type name could be changed to any global symbol simply by replacing the two occurences of :-person_type with :-footype, or whatever.
4. Despite this thing with the global type name, the object-module itself is still 100% local and inacessible (via ordinary, non-hacking means) to the outside world. (The primary hackish means of accessing module locals from the outside is setting kernelopts(opaquemodules= false), which allows module locals to be accessed via the A:-B syntax as if they were exports.) ​​​​​​

@MapleEnthusiast Do you have ranges to bound all the parameters? If so, I would start by finding ranges for each matrix entry. The Maple command evalr can do this. Then try to apply the Gershgorin circle theorem.

Regarding the Collatz-Wieland formula: There are a number of generalizations of it and related spectral inequalities in this Wikipedia article: Perron-Frobebnius theorem. While these generalizations only apply to non-negative matrices, this article is extremely detailed and worth reading (although its style is a bit more colloquial than the typical Wikipedia article).

Would you please define precisely what you mean by "the largest eigenvalue (not in absolute value)"? How do you order the nonreal eigenvalues without using absolute value? (On the other hand, it's trivial to prove that 1 itself is an eigenvalue of any square matrix whose rows sum to 1, regardless of the signs, arguments, or magnitudes of the entries.) 

I think that the algebraic/polynomial approach that you've begun (i.e., finding algebraic expressions for the eigenvalues) is doomed due to the infeasibility of the computations, in particular the inequality computations.

@mmcdara You wrote:

• Thanks acer for correcting me on the number of digits that some _d01ajc  can handle. If I have thought it there was such a limitation, that is because, while I was working on Mehdi's example, I got an error message...:

  Digits:=20:
  evalf(Int(x, x=0..1, method=_d01ajc))
  Error, (in evalf/int) expect Digits<=15 for method _d01ajc but received 23
  

There is a limitation; however, I think that acer meant that that limitation is not as strict as you may have believed. The overall computation is limited to Digits <= 15, but the integrand evaluations can be done at higher precision, as in

Digits:= 15:
Sin:= proc(x::realcons)
    Digits:= 20;
    evalf(sin(x))
end proc
:
evalf(Int(Sin, 0..Pi, method= _d01ajc));

If acer meant something substantially more general than this, I hope that he'll say. (Note that Digits is what is called an environment variable: a global variable whose value, when changed within a procedure, reverts to its previous value upon the procedure's exit.)

• Would the plot command automatically apply evalf?

Yes, or evalhf if that happens without error. This is not a special property of Int wrt plot; plot will do it for any procedure.

• I agree with both of you that explicitely specifying the tolerance or using epsilon option would be a better way to get the desired accuracy.

I don't know what you mean by "or" in that sentence. The epsilon option is the way to explicitly specify the tolerance.

@acer In this paragraph:

• int(eval(A1+A2,omega=20.099752),theta=0..Pi, numeric, digits=5) 
  is not the right way to get 5 accurate digits in general, or even to force a coarse tolerance near say 1e-5.... More approriate is to specify the accuracy tolerance explicitly, instead of having it be implied by an unholy low value for the working precision.

I believe that what acer means is that it's better to use the epsilon option to int to control the precision; the digits option only controls the precision of the sub-computations. If that's what he means, then I wholeheartedly agree. (I'm only posting this Reply because he didn't explicitly mention the epsilon option in that paragraph.)​​​​​​

@MapleEnthusiast Suppose that somehow you eventually got 4 large symbolic expressions for the eigenvalues. Since it's a 4x4 matrix, this can be done by solving a 4th-degree polynomial; so, it is doable, and the expressions would only be, I guess, a few pages long (prettyprinted). Now how would you go about comparing the magnitudes of those expressions to 1? This seems to me to be a task far more complicated than getting the eigenvalues algebraically via the quartic formula.

@acer I did that to fake the unlabeled subticks. It's still not 100% what I wanted because fake subticks are the same length as regular ticks but true subticks are shorter.

Also (as I'm sure you're aware), multiplication by the degree symbol doesn't typeset properly.

@vv Yes, you're right. The part about moving mod to the end must be used with caution, and only when one knows that it'll be appropriate.