There are two different problems specified, and it doesn't seem like you realize that they are different. The first is the problem specified in your paragraph labeled "1." The second is the problem in the paragraph after that. The region labeled "2" in the graph corresponds to this second problem; however, the region labeled "1" does not correspond to paragraph "1." So, please clarify the Question.

@C_R At ?seq, it says

• The form seq(x) is equivalent to seq(i,i = x).

So, seq(R) where R is an rtable is a sequence of the elements.

Any procedure or function name f (or sequence of names) can be enclosed in { } or [ ] so that {f}(...) = {f(...)} and [f](...) = [f(...)]. This is documented at ?evalapply.

For me, {seq}(...) is much more clear to read than {seq(...)} (especially when the (...) is long) because the former makes it immediately obvious that the set is formed strictly from the result of the seq, whereas with the latter form one needs to read ahead to the closing } to know whether the set contains something in addition to the result of the seq.

And, since I always use the form {f}(...) when it's applicable, if I see {f(...)... in my own code I know immediately (without needing to look for the }) that the set contains something in addition to the result of f(...).

The notation "..." appears twice in expression pp. It isn't valid Maple syntax. What do you mean by it?

@michaelvio There's no way to "close" a Question in the sense of preventing further Answers and Replies. The closest thing to that would be to select an Answer as the "Best Answer" by clicking on the trophy icon in the Answer's upper-right corner, under the timestamp.

Do you want to do this operation once, which would make the easiest method preferable, or repeatedly (as in a program), which would make the most-efficient method preferable?

At one point, you issue the command Dsolve(ODE2, y(x)) and conclude that Maple couldn't solve the ODE. But what's really happening is that there's no command Dsolve (it should be dsolve).

@Axel Vogt Yes, I agree about Digits:= 15. It is the best value for most (but definitely not all) situations. By "best", I mean that it gives the best balance of speed and precision. This has little to do with Maple and a lot to do with the IEEE-754 Standard floating-point computations that are optimized into nearly all 64-bit processors.

@mehran rajabi 

Firstly, this was stated by others, but I want to restate it more adamantly than they did: This is a linear differential equation, not a nonlinear one. 

Extracting the coeffiecients in this case requires not only the PDEtools:-dcoeffs suggested by @ecterrab but also the command content to get rid of the x parts:

ode:= 
    c1*diff(f(x),x$4) + c2*diff(f(x),x$3)/x +
    c3*diff(f(x),x$2)/x^2 + c4*diff(f(x),x)/x^3 + c5*f(x)
:
content~([PDEtools:-dcoeffs](ode, f(x)), x);
                      [c1, c2, c3, c4, c5]

Note that I've entered ode not as an equation but as an expression implicitly equated to 0. Most Maple commands do not force you to use one or the other; however, dcoeffs requires the latter.

@acer Geez, I was looking through package ContextMenu for over an hour trying to answer this Question, and you're saying (essentially) that that package isn't being used? For example, I tried

P:= plot(x^2, x= 0..1):
ContextMenu:-Test:-ListMenuEntries(P);

That listed 241 menus in plaintext form, none of which seemed relevant, and the majority of which had nothing to do with plots. Since the context menu for a 2-D plot has an entry for a submenu named "Axes", I was searching the output of various ContextMenu commands for the string "Axes", but I never found it.

How can one use this package in this "context"?

@ecterrab Thanks. I was totally unaware of the dsolve syntax that uses [f, {...}] as the second argument.

@nm You wrote:

• I do not want to add code to keep checking if m and n are type numeric just to avoid using is and to  just normal n<=m just to save few nano seconds.

I'm not suggesting that you do a type check for numeric. In the vast majority of cases, I know a priori (meaning, at the time that the code is written) that both sides are numeric. Your example of using a type check to decide between the two is, of course, ridiculous, and I would never suggest doing that.

• So I think using is all the time makes the code simpler, as it works in both cases. Right?

No. There's a small chance that is will take a very long time, perhaps get stuck, perhaps return FAIL. The default boolean evaluation would never do any of those things, but is is a house built on sand. It's a weak command IMO. You're suggesting changing every Boolean condition in all your code to is. You batch process thousands of cases at a time, right? Do you really want to add thousands of instances of the use of a command that has even a small possibility of getting stuck? I suggest that you only use is in those cases where one of the sides might be non-numeric. If you're saying that that's all your cases of using an inequality with if in all your code, then I don't believe you. If, on the other hand, you actually mean changing all the cases in a few large programs, then I believe you.

@nm I just substantially updated my Answer to address some of those issues.

I can easily eliminate one of your three boolean evaluators: Since if a <= b does exactly the same thing as if evalb(a <= b), there's no need for the latter. evalb is only needed when an inequality (or other relation) is used in a context that doesn't automatically imply that it needs to be reduced to true or false (or FAIL, depending on the context).

I don't think that you should change all your code from evalb to is! Only do the cases where you're not sure that both sides are type numeric.

Should an unsolicited link for another CAS be considered spam? I lean towards "No", but I'm unsure. I think the OP should post some examples of what there CAS can do.

@Carl Love I just updated the code above, making it significantly faster in the case that the number of desired small divisors is large, yet still a small fraction of the total number of divisors. This is shown in the last example in the worksheet.

@felixiao Obviously there is a pattern to all the T matrices, T11 to T36. You need to discover the pattern, then abstract it and generalize it into a procedure. You should be able to make a procedure of about10 lines that constructs all the T matrices.

Your code is extremely unwieldy. It needs to be divided into several execution groups, or procedures. Using 2D Input also makes it difficult.