@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.

@Ioannis The plot that Rouben posted above (vote up) shows two paraboloids. The one on the right is much flatter than the one on the left, and this causes an optical illusion that makes it more difficult to see it as a paraboloid. The two paraboloids could be more easily distinguished with color or some other artifice, but, for the time being, I'll leave it to Rouben to make that embellishment (if he chooses) because I have more-pressing things to do.

@mmcdara Your timing is not accurate because CodeTools:-Usage doesn't account for the fact that the result of ifactor (and thus also ifactors, essentially) is cached.

I suspect that your code could not easily handle the number shown in my example immediately above because of the powerset being much too large.

You should be able to run the procedure immediately above in Maple 2015. Perhaps you'll need to change mul(S) to mul(x, x= S) and likewise for mul(S[2..]).

This procedure below does the same as my Answer above, in essentially the same way, but it illustrates how the computation is performed via repeated application of the geometric sum formula to the prime-exponent pairs of the prime factorization. The number tested in the example below is so large that even listing its divisors or iterating through them is totally out of the question: There are ~1 quadrillion = 10^15 of them.

SumOddComplementDivisors:= proc(n::integer)
local P, S;
    if n=0 then infinity
    elif abs(n)=1 then 1
    else
        P:= ifactors(n)[2];
        S:= map(p-> (p[1]^(p[2]+1)-1)/(p[1]-1), P);
        `if`(n::odd, mul(S), (S[1]+1)/2*mul(S[2..]))
    fi
end proc
:   
n:= 2^29*mul(ithprime(k)^rand(1..9)(), k= 2..19)*nextprime(2^29);
n := 39943730387748903870428897494573005555549238795858219140794\
  08427992979376542681824710226320630046887046180225126687753224\
  85014780614541312000000

CodeTools:-Usage(SumOddComplementDivisors(n));
memory used=98.26KiB, alloc change=0 bytes, cpu time=15.00ms, 
real time=4.00ms, gc time=0ns

1531661487716093169531385014455233133797946665998965276549256385\
  11203272409082014900523213313509988736347844419100663992744771\
  3886226087936000000

#Count the divisors:
NumberTheory:-SumOfDivisors(n,0);
                        999959385600000

evalf(%);
                                      14
                        9.999593856 10  

ifactor(n);
    29    7    6    2     4     6     5          8     5     2 
 (2)   (3)  (5)  (7)  (11)  (13)  (17)  (19) (23)  (29)  (31)  

       2     4     8     3     9     2     8     9            
   (37)  (41)  (43)  (47)  (53)  (59)  (61)  (67)  (536870923)

@mmcdara The name that I used for my procedure, SumOddDivisors, may have caused your surprise/confusion. I'll admit that I should've come up with a better name. My procedure doesn't sum the odd divisors, but it does do what the OP wants: It sums the divisors d such that n/d is odd.

I'm at a loss for a good name for this, and suggestions are welcome. How about SumOddComplementDivisors?

@Kitonum It's extremely inefficient to loop through all positive integers i <= n. Your procedure is essentially unusable for n > 10^8. At the very least, your procedure should be modified to

S := proc(n) 
local i, s;
uses NumberTheory;
s:=0; 
for i in Divisors(n) do 
    if type(n/i, odd) then s:=s+i end if; 
end do;
s;
end proc:

It's shocking that this Answer was awarded 2 votes up and Best Answer.

@nm SemiAlgebraic only works for systems of polynomial equations and inequalities, and perhaps some cases that can be easily converted to polynomials.

Are A and B always polynomials? 

Don't edit your Question such that it becomes a completely different Question. It's extremely rude if the Question has already been Answered, as this one has been.

If you have an unrelated Question about matrix arithmetic, start a new Question thread.

@nm The partial fraction decomposition depends on the factorization of the denominator used. The presence of the nonreal I suggests (but does not mandate) that a splitting into linear factors is desired. So Maple's result and your analysis of it are correct if the given factorization as a square of an irreducible quadratic is the desired factorization. In that case, it's considered irreducible over the field of rationals extended by I.

@acer Your 3rd procedure, mm1sub3, ignores its 1st parameter, x. I can't tell if that was intentional or an oversight. If it was intentional, please explain why you did it that way.