@acer Thank you for the Reply. Hopefully my wording of the concepts will provide the OP with additional insight. Alternate wording often helps me understand. I managed to do all that without reading the OP's originally attached worksheet. This problem that MaplePrimes won't display the worksheets is becoming quite a burden, especially since about half the time I'm just using my phone.

You've said things several times over the years that indicated to me that you had some detailed knowledge of how worksheets are "rendered" for display on MaplePrimes ... well, at least more-detailed knowledge than the vast majority of the MaplePrimes regulars. So, I'd like to ask you something: Since Maple can export worksheets as PDF, and since (I assume) it's very easy to display a PDF in a web browser, wouldn't that mechanism make for a much-easier way to display the worksheets here? At the very least, if every attached worksheet were also attached as a PDF, I'd be able to read them without needing Maple, because my phone can easily display PDFs.

@Wilks 

Regarding the error message: The dsolve command is complaining because it can't decide which Y2 to solve for: Y2(x) or Y2(L[2]). This is totally obvious to us, but not to dsolve. The solution is to tell it which function is the primary in dsolve's 2nd argument:

dsolve({...}, Y2(x));

where ... is exactly what you already have inside the { }.

Regarding your question about constants of integration: If you do indefinite integration with int, it doesn't supply a constant of integration^[*1], as you already know. The command dsolve can also do both indefinite and definite integration, but in the indefinite case it will supply the constants. To see this (just an an instructional example; it's definitely not actually needed here), simply remove one or both initial conditions from the dsolve command. In the definite case, the issue of the constants is handled internally. I suppose that in many cases it does exactly the same steps that you'd do "by hand": First include the constants, then use the initial conditions to solve for them. I'm not sure about its exact internal process, but it is internal, so you do not need to concern yourself about the constants.

Regarding restart (which you didn't ask about): It's almost essential (as well as being standard practice) that you begin every worksheet with restart. Although this particular worksheet seems to work without it (in precisely its current state), you will almost certainly eventually cause some error by not using it. These errors will not manifest until you re-execute the entire worksheet in the same session.

The commands Y1:= 'Y1' and Y2:= 'Y2' aren't needed (yet) in this worksheet, but if they had been needed, it would be much more likely that such an absence-of-restart error would occur. I usually see the presence of these commands as a sign of sloppy programming because their presence obscures potential sources of error.

Congratulations! With much perserverance over a month or so, we've finally made this worksheet into a readable document.

[*1] The reason that int doesn't supply a symbolic constant is that the mathematical constant (such as the +C that's ubiquitous in calculus textbooks) is only truly constant when the integrand is continuous. In the discontinuous case, it needs to be a piecewise-constant function that branches at the discontinuities.

@Kitonum Although this is probably obvious to anyone who's worked extensively with indexed structures (in any language), it should be pointed out for naive readers that what you show beginning with the line L1:= ... can only work if the entries are distinct, i.e., if the structure represents a bijection between its indices (which are necessarily distinct) and its entries. Or, in slightly less-technical language, an indexed structure has a pointwise inverse^[*2] structure iff it represents an invertible function.

Nonetheless, it's easy (and remarkably efficient) to construct the setwise inverse^[*1] table for any table or rtable by using ListTools:-Classify, as in this example:

M:= LinearAlgebra:-RandomMatrix((9,9), generator= rand(0..9)):
M_inverse:= ((op@[lhs]~)~@ListTools:-Classify)(rhs, [indices](M, ':-pairs')):
#Remove op@ from above command if you want explicit sets.
M_inverse[7];
             [1, 8], [1, 9], [3, 3], [4, 2], [4, 3], [9, 1], [9, 5]

In other words, the end result of the above is all pairs (i, j) such that M[i,j] = 7.

[*1] My terminology setwise inverse is perhaps nonstandard. Thus: Definition: Given a function f: A -> B, the setwise inverse of f is the function g: B -> 2^A defined by g(y) = {x in A | f(x) = y}. The set g(y) is called the preimage or inverse image of y under f. Note that any indexed structure can be thought of as a function of its indices. All symbols and words in these footnotes mean what they commonly mean in set theory, which is not necessarily what they mean in Maple.

[*2] By "pointwise inverse structure (or function)", I simply mean inverse function is the ordinary sense. I just used pointwise in contrast to setwise.

@Rouben Rostamian What you suggest---op(node[...])---would only work if node[...] were an unassigned name, not a table or rtable entry.

@nm With all due respect, I disagree with your opinion about posting the problem as a picture. It's best for the OP's own learning to type it in correctly. It also makes copy-and-paste easier for the respondents. Responders usually don't want to type in a whole problem from a picture.

In this case, the OP seems too lazy to correct the typing of their problem, despite numerous corrections from responders here.

If you'd care to amend your suggestion to "post a picture AND type it in (or at least try to)", I'd agree with you.

@ogunmiloro Due to your Maple version, just use interface(rtablesize= infinity). Individually setting the allowed number of rows and columns is a rather recent innovation. 

@Wilks The fact that you no longer want the constants of integration to be 0 makes no difference. There's no need for any solve, int, or intat; there's no need to ever see or even name the constants. All of that can be replaced by a single call to dsolve. The constants will be determined from the initial conditions, which are passed in the first argument to dsolve. 

@SUA 

Errors:

1. You continue to write D[1](C)(t) even though we just agreed above that it should be D[1](C)(infinity, t).
2. D cannot be an "empirical constant of the equation".
3. In IC[1], Z should be z.

@Wilks Here is the direct answer to your question about function Y2 and its error. However, knowing this answer won't completely fix your problem. Nonetheless, this is something very important to learn; you've consistently made this same mistake numerous times; indeed, it's your most-common mistake.

Here's your definition of Y2, translated to 1D input:

Y2:= x-> int(Y21(x), x) + C22:

So, Y2 performs an integration with respect to its parameter, x. An integration (in Maple at least) must be performed with respect to a variable (or a name in Maplese). So any attempt to replace x by a number or a symbolic expression more complicated than just a name makes no sense to the int command, and it returns an error.

Often one wants to perform a computation along these lines:

1. Given: An expression e with a symbolic parameter x.
2. The first part of the computation involves some sort of symbolic manipulation of e which requires x to be a variable. Some common examples are solve, int, diff, limit​​​​​​.
3. The second part of the computation involves replacing x with some expression (numeric or otherwise) other than a simple variable.
4. We want to do step 3 multiple times; we want a function for it.

The solution to this is to use command unapply rather than x-> ... to define the function. In the specific case at hand:

Y2:= unapply(int(Y21(x), x) + C22, x);

@adel-00 I'm not suggesting that you try symbolic integration, nor did I ever suggest it. I'm more than well aware of the complexity of your expression. 

Considering it as an expression only suitable for numeric evaluation, it's actually not all that long. I've dealt with far longer expressions, and successfully integrated them numerically. I don't know the root cause of the numeric instability, but I'd guess that the length of the expression has little to do with it.

None of this explains why you've ignored the previous advice, essentially going back to square 1. Your method will not work. You need to accept that before we can make progress. By obscuring the fact that this was about numeric integration, you've caused Tom and acer to waste time making small corrections to your code, which unbeknownst to them was just adding some meaningless numbers.

Acer is quite an expert of numeric integration. I'm eager to see if he comes up with something.

@Wilks Please attach that same worksheet that you show screenshotted above. You'll almost certainly get an error message (embedded in your post) from the MaplePrimes editor. However, just ignore that error message, and I'll be able to download the worksheet anyway. (The error message regards the inline display of the worksheet, not its being attached as a file.)

I have assumed that

1. @SUA  (the current OP) and @ShahramUA are the same person.
2. This Question is a more complete version of the very incomplete Question posted by ShahramUA 2 hours ago.

Thus, I deleted the Question posted under then name @ShahramUA.

Like Tom, I can guess that by f you meant C. But I don't know how to interpret D[1](f)(t) or D[1](C)(t). Do you mean D[1](C)(infinity, t)?

This is essentially a duplicate of the OP's prior Question "How to eval integration under loop". The OP appears to have cleaned up this nasty expression a tiny bit, but is ignoring the extensive advice that I already gave there in multiple Replies over the course of several days, involving considerable effort for both me and my computer.

Since a few weeks have passed, and since Tom and acer have provided new material, I vote that we let this stand as a new Question. Anyone who has responded to this Question or is considering responding to it would do well to review the responses to the prior Question.

@mmcdara You wrote:

• You write "This procedure does the same as my Answer above"

The "this" in my sentence that you've quoted is not referring to your procedure; it refers to my procedure that follows in the same Reply. Indeed, this (or its plural these) often refers to something following in the writing, whereas that (when used as a pronoun) (or its plural those) always refers to something preceding in the writing.

•  Maple 2015 does not have a procedure equivalent to SumOfDivisors

The equivalent in Maple 2015 (as well as much older Maple) is numtheory:-sigma.

• combinat:-powerset(F):
  add(map(u -> mul(op(u)), %))*k

  To conclude I do not pretend to have done something original.

Actually, that does seem original. However, it's totally infeasible when the number of divisors is large. As I said before, there's a simple formula to compute the sum of the divisors without needing to iterate through them:

#If the prime factorization is
n = Product(p[i]^e[i], i= 1..k);
                                   k             
                               ,--------'        
                                  |  |           
                                  |  |       e[i]
                           n =    |  |   p[i]    
                                  |  |           
                                 i = 1           

#then the sum of the divisors is
sigma(n) = Product((p[i]^(e[i]+1) - 1)/(p[i] - 1), i= 1..k);
                                  k                       
                              ,--------'                  
                                 |  |       (e[i] + 1)    
                                 |  |   p[i]           - 1
                   sigma(n) =    |  |   ------------------
                                 |  |        p[i] - 1     
                                i = 1                     

• I have already be surprised by the results  CodeTools:-Usage and I generally use time() instead before and after a loop were the code to test is executed many times.

You are not achieving any benefit by doing that. In particular, you are not overcoming the inaccuracy in the timing that results from caching (a.k.a. memoisation), not to be confused with the processor-based hardware memory caches L1, L2, L3. You should stick with CodeTools.

• Maybe this is also due to this notion of "cache".

"Cache" is ambiguous (see the last paragraph). I am referring to option remember and option cache. If you read the code of ifactor by the following method, you'll see that it uses option remember. (And the difference between these two options is not very relevant to this measurement-of-time issue.)

interface(verboseproc= 3);
eval(ifactor);

Note: Reading the code the "normal way" with showstat will not reveal the options.

• Is this mentionned somewhere in the help pages?

I don't recall having seen it. And the help pages (and manuals) have extremely little information about accurately timing Maple code. Everything that I know about it has been learned through experimentation, which I've spent hundreds (perhaps thousands) of hours doing.

I think that these two statements taken together provide a convincing argument that timing a "dumb" repetition of some code is inaccurate in the presence of memoisation. The first of these statements is outright obvious. The second can be easily verified by experiment.

1. If some code does not execute the steps needed to perform a computation because it's simply retrieving the results from the last time that it performed the computation, then it's not being accurately timed.
2. If code has implemented memoisation, some generic timing procedure is not going to be able to turn that off.