@ijuptilk Your problem is likely caused by the lines "Approximate eigenvalues" and "Precise eigenvalues". These lines are comments and you're treating them as code. To keep these lines, use # to tell the parser that they are comments:

#Approximate eigenvalues
#Precise eigenvalues

@ijuptilk The procedures pindex and simple_deflat from the PDF can both be replaced by this simple procedure:

simple_deflate:= (A::Matrix, u::Vector)->
    (p-> A-u.A[p]/u[p])(max[index](abs~(u)))
:

This code also addresses the "ill-conditioning" issue mentioned in the last line of the PDF by selecting the entry of maximal absolute value rather than any nonzero entry.

If your Maple version is too old to have max with the index option, let me know, and I can modify the above. You'd be able to tell immediately from the help page ?max.

@Earl Yes, Kitonum's Answer assumes a uniform density of 1. Regardless of whether the density is uniform, it can be accounted for by including it as a factor of the integrand in all of the integrals (2 for the center of mass and 1 for the moment of inertia). If that factor is constant (uniform density), it can be pulled out of the integrals. The dimensions of moment of inertia are mass*length^2.

@mnovaes The command subs has much more general uses than substituting values for variables. It can substitute any expression for any other expression provided that the expression being searched for exists as a distinct entity within the expression being modified. I fairly often substitute one number for another. About half of the time that I do this, the number that I want to change is represented by a variable. If subs treated x as a plain name in the following code, then I wouldn't be able to do that number changing:

x:= 3:
subs(x= 4, 3);

Maple can generate a "series" solution for your ODE, meaning the exact values of any finite number of leading terms of something akin to a power series for b(x). Specifically, it returns _C1*P1(x) + _C2*P2(x) + _C3*ln(x)*P3(x) + P4(x) where the _Ck are constants of integration and the Pk are power series with rational coefficients truncated to some finite order that you can specify.

Order:= 20: #desired truncation order
dsolve(
    diff(b(x),x$3)/2 + diff(b(x),x$2)/x + 
        2*diff(b(x),x)/(x^2+1)^2 - 4*x*b(x)/(x^2+1)^3, 
    b(x), series,
    x= 0 #expansion point (any complex number or `infinity`)
);
Order:= 6: #reset to default value

There are other cases where it's possible to get a "formal series" solution, meaning explicitly expressed as infinite sums, but I can't do it with this ODE, despite the fact that the reformulated ODE is homogenous and linear with integer polynomial coefficients.

@Angie7 In the 2nd of my 3 answers, change x(1) to D(x)(1).

I deleted your earlier version of this Question. I see many errors in your code, but I'm on my phone (no Maple) right now. I'll Answer soon if someone else doesn't get to it first. The command fsolve is very good with numeric polynomials.

Please post a worksheet showing the error. I can probably fix the error, but my knowledge of ADM (Adomian Decomposition Method) is limited to this Wikipedia page "Adomian Decomposition Method". There is a good and rather throrough example on that page of solving a nonlinear BVP with a boundary condition at infinity. See the section on the Blasius equation. The BVP is

diff(u(x), x$3) + u(x)*diff(u(x), x$2)/2 = 0, u(0)=0, D(u)(0)=0, D(u)(infinity)=1

@vv I am not advocating ignoring the userinfo from the 1st call. But, the OP definitely wants that info from the 2nd call only. The purpose of this Answer is to show that it's efficient to repeat the dsolve to achieve that.

@nahid200 Sorry, but I still don't understand it. I understand everything below the phrase "For this purpose", but I don't understand the little bit above that phrase. In particular, having two non-integer arguments makes no sense to me. Furthermore, note that there's nothing in your box below that phrase about B having two arguments, nor are the Greek letters zeta or gamma used in that paragraph.

You wrote:

•  it works for  n,m=1,2,3..., but doesn't work for n=0.1,0.2,0.333, and m=0.1,0.2222,0.44

Yes, that's totally 100% obvious---so obvious that it's nearly ridiculous that you wrote it out. It makes absolutely no sense to me for n and m to be anything other than positive integers. That's not a limitation of Maple; it's just common sense.

Perhaps you could cite some reference material that I could look up about this?

The version of procedure B with 16-lines of code in your most-recent Reply does the same thing as the 7-line version from your Reply before that. The extra lines do nothing other than waste time and make the code confusing. Stick with the 7-line version.

I asked you two other questions In my previous Reply that you haven't answered:

• one about the starting values of r and k;
• one about spline versus linear.

Anything that you can say about these questions, even if it's only a little bit true, will help me understand. 

In all future postings, please mark off very clearly anything, including code, that you're quoting from another source. This has nothing to do with copyright or intellectual honesty; it just helps me to understand what you don't understand so I can figure out an approach to explaining it to you.

@nahid200 I don't understand what you want in your most-recent question. The code snippet that you showed would create m independent Wiener processes on the interval 0..1 discretized into n subintervals. Of course, n and m are necessarily positive integers. Any of those m Wiener processes could be evaluated at 0.8 or 0.2 (since those are in the interval 0..1); but why do you want the simultaneous evaluation at both numbers that's implied by B(0.8, 0.2)? Why does your r start at 0 but k starts at 1?

Is there a reason that you want to use spline interpolation rather than the linear interpolation that I already showed? I don't have any specific reason for preferring one over than other; I'm just curious. 

@tomleslie Thanks for correcting my Maple-version mistake. Statistics:-CumulativeSum is a fine alternative to ArrayTools:-ScanAlongDimension.

@nahid200 The "unable to parse" error that you reported couldn't possibly be due to the error that Tom found. It seems related to the method you used to copy-and-paste the code into your worksheet, and possibly that's due to using 2D Input (as opposed to the plaintext 1D input). Anyway, if you can run Tom's correction of my code, then use that.

@nm There are conflicting definitions of output being used implicitly in this thread, and conflating them is the source of your contention. The output of a function could mean either

1. the things displayed on the screen (or some other file) after invoking the function; 
2. the return value of the function, which could be assigned to a variable.

I totally agree with you that "we all learned at school" that a function's output should depend only on its input; however, in that rule "output" is only meant in sense 2 above. If we want to strictly use output in that sense, then what userinfo^[*1] produces is called side effects, not output.

Some purists teach you "at school" to avoid side effects. That's a great discipline to learn in one's early stages of learning, but efficiency requires one to use side effects sometimes.

[*1] The command that produces the sense-1 output being discussed in this thread is userinfo; the table infolevel is only a means of passing information to userinfo. Thus, you should call it the output of userinfo, not the output of infolevel.

@mmcdara I assumed ordinary Maple integers 0..999 were what the OP wanted. If instead they want something that displays in an upright font (like an ordinary integer), doesn't have quotes, and has commas inserted in the usual way, then I can write a procedure for that.

VV's Answer gets to the heart of the issue (vote up!), which is that what you're seeing is an entry retrieved from a remember table without evaluation. I have three "furthermores" to add to that:

1. It doesn't matter whether you use W(x):= ... or assign(...); either will lead to the issue that you reported.
2. The _C1 that you still see after setting _C1:= 0 is indeed 0; it just hasn't been evaluated yet (because it's a remember table retrieval). When that expression is next evaluated, its _C1 will be explicitly set to 0. You can verify this by doing
   W(x); %;
   and noting that the two expressions are different and the 2nd has no _C1.
3. It doesn't matter whether you use _C1:= 0, eval(..., _C1= 0), or subs(_C1= 0, ...); the issue is caused by assigning to W(x), and it'll remain regardless of how you specify a value for _C1.

So, don't make assignments to W(x) unless you truly intend to make a remember table assignment (which is unlikely if you haven't assigned a procedure to W itself). Do this instead:

W:= unapply(rhs(sol1), x);
W__particular:= unapply(
    eval(rhs(sol1), indets(sol1, suffixed(_C))=~ 0), x
);