Attempting to delete the above as spam causes a redirection to a web page about "block chain" investment.

@C_R I think that it's clearly documented near the top of the page ?dsolve,details that if the ODE system contains derivatives of unknown functions that are not intended to be solved for, then the functions that are to be solved for need to be specified as the second argument.

@Carl Love My Reply above, "Your examples are inconsistent", has been substantially updated, showing a way to hand both examples with one procedure, provided that you can specify which operations you want to be inert. This usually only requires the putting in some % signs.

@acer @Christopher2222 There a pull-down "Order answers by" on the right side of the top line of the header of whatever Answer happens to be shown first. The choices are Votes, Date (newest first), and Date (oldest first). Choosing either of the Dates might stabilize the order for you. The Date orders do make something different, but they don't work as expected. In any case, if you change the order with this pull-down, you'll be offered an opportunity to make the new order your default.

@paulmcquad Your output goals for your two examples are inconsistent with each other. In your first example, Sum(i^2, i= 1..5), your want the squaring---an operation that's internal to the summand---to be inert. In your second example, Sum(1/(k+7), k= -2..3), you want the addition of 7---an operation that's also internal to the summand---to not be inert. Indeed, this second example seems to also be inconsistent with the goal you stated in this thread's title, that being the explicit printing of the indices of summation.

Nonetheless, your second example can be handled by this procedure:

EvalSum:= proc(
    S::Sum(algebraic, name= range(integer)), {active::truefalse:= false}
)
uses T= Typesetting, IF= InertForm, LT= ListTools;
    (T:-mrow @ op @ rcurry(LT:-Join, T:-mo("=")) @ 
        rcurry(IF:-Display~, 'inert'= not active)
    )
        ([S, `%+`(`$`(op(S))), value(S)])
end proc
:
EvalSum(Sum(1/(k+7), k= -2..3));

Your first example can also be handled by the same procedure, provided that you explicitly specify your desired inertness of the squaring:

EvalSum(Sum(i %^ 2, i= 1..5));  #The % makes it inert

In either case, the keyword active can be included to change the default grey display of inert operators to same default color as the rest of the output (usually blue). This only changes the color used to display the inert operators; they still remain inert.

EvalSum(Sum(1/(k+7), k= -2..3), active);

@Christopher2222 The order hasn't been changed as far as I can tell. What seems out of order to you?

@acer Here's a procedure that combines our approaches. That is, it's a procedure that takes a single argument--an ordinary finite Sum--and applies MakeInert to the summand. Then it formats the three branches of = with Display(..., 'inert'= false). Then it interleaves the mo("=")s.

EvalSum:= proc(S::Sum(algebraic, name= range(integer)))
uses T= Typesetting, IF= InertForm, LT= ListTools;
local e:= applyop(IF:-MakeInert, 1, S);
    (T:-mrow @ op @ rcurry(LT:-Join, T:-mo("=")) @ rcurry(IF:-Display~, 'inert'= false))(
        [e, eval(subsop(0= sum, e)), value(e)]
    )
end proc
:

If floating-point numbers (aka, decimals) are okay for you, this is very easy; I could write it in under 5 minutes. So, are they okay?

Do your matrices have real entries? And, if so, are they symmetric (such as the adjacency matrix of a non-directed graph)? I ask because you ask for the minimum and maximum eigenvalues; however, the eigenvalues of real matrices are, in general, non-real, unless the matrix is symmetric.

@dharr Your seq commands can be simplified a bit (I'm not saying that they should be simplified) to

MMFlatten:= (Q::Matrix)-> local i; <seq(`<|>`(seq(Q[i])), i= 1..op(1, Q)[1])>:

For a Matrix Q, Q[i] returns the entire ith row.

@Rouben Rostamian  You wrote:

• [T]he roots within each cluster are pretty much equally spaced, so it would be difficult to miss any one of them.

The roots within each cluster are evenly spaced by pairs, that spacing being 2*Pi, but the distances between the pairs' members are much smaller than that. That is shown in the following close-up plot of the first cluster. There are 61 apparent crossings of g=0, each of which represents 2 actual crossings.

g:= 199/200 - cos(surd(s,3)/4)*sin(s):
plot(
    [-g, (r:= [[1800,0],[2181,0]])], s= `..`(r[..,1][]), 
    view= [DEFAULT, `..`((-1,1)/200)],
    size= 280*[5,1], thickness= 0.15*[1,4], color= [red, black], 
    axes= frame, numpoints= 2^13
);

Note that the distance between the roots in a pair will be closest for the first and last pairs of a cluster. Whatever the precision (Digits) is set at, these will likely be the first cases where extracting the roots consecutively fails for that precision.

I just noticed that you used A in two ways in your code: as the lower limit of integration and as the name of the Array. It's very likely that this caused your errors, and even if it didn't, you should change the Array's name to something else.

In my code above, that problem doesn't show up, which is why I didn't notice it until now. In my code, the inert form of the integral expression is created before A is made into an Array. Within the inert form, A is encoded as a string constant, "A", which makes it immune to change. You can examine that inert encoding via lprint(J).

Also, it's not necessary to use inert forms to use long mathematical expressions as multiple choices; you can also use ordinary Maple expressions created via either 2D- or 1D-input. I used an inert form so that I could represent your expression into a form close to what you had.

@emendes The important thing is whether rho is less than or greater than 1; rho being positive but not necessarily greater than 1 is irrelevant. Assuming beta > 0 is not problematic by itself.

There is no variable sigma in this problem. If you actually meant signum, that's a Maple function name. The assumptions should be made on beta and rho such that the value of the argument of signum is positive, which'll make the signum expression equal 1. Above, @dharr used 

assuming beta > 0, rho > 1, -1 - sqrt(beta)*sqrt(rho - 1) + rho > 0;

The purpose of the last of those assumptions is to determine the value of the signum expression.

Two general tips for assumptions:

1. If a variable appears alone on one side of any inequality in a assumption, then also assuming that it's real is never necessary.
2. I usually find assuming easier to work with than assume.

@aroche In your first equation, the first sqrt encompasses the denominator; in Ed's original it does not. But anyway, the first equation is superfluous; the xi__8 cancels, leaving a tautology.

@nm It is a Riccati equation; however, this classification doesn't help Maple to solve it. As you showed, Maple's dsolve needs no help or prompting to solve it, See the Wikipedia article "Riccati equation",

It wasn't obvious to me whether the above approach would work over an extended finite field (i.e., one with p^k elements where p is prime and k > 1). The worksheet below shows that it does work.

Download ModParfrac.mw