The Display settings are in the Options dialog/menu. In Maple 2023, Options is accessed from the Tools menu, but in Maple 2025 , Options is the last item on the File menu.

While your typing cursor is in an input field (usually, that's a line with a > on the left), go to the Edit menu. Is there an entry "Switch to Math Mode"? If so, select it. Then try typing something. Does that make any difference, and is it the difference that you want?

The moral of this story is that Maplesoft should test code both with and without the with command.

@dharr Your Answer has some good tips on indexing, but it has nothing to do with the cause of the OP's problem. The error message "invalid subscript selector" can only come from applying an invalid numeric index to a set, list, or expression sequence. In this particular case, in the 3rd iteration of the loop (i=2), dsolve returns NULL. Thus S[2] = NULL, which is an expression sequence, and thus S[2][1] has an invalid subscript selector.

In Maple 2025 (which the OP didn't use), you are getting Typesetting errors in the loop that sets up the conds. There are two easy workarounds for these. The first is to set interface(typesetting= standard). The second is to not use PDEtools:-declare.

In Maple 2025, dsolve works for S[2], but fails for S[3].

@acer The spam button is gone now!

I'm amazed that several hours of work was done on MaplePrimes this morning, yet this Post hasn't been deleted.

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.