@tomleslie Thanks. Yes, you're right, and I'm about to correct the Answer.

@acer In the case of my procedure / appliable module that's being discussed, the ModuleApply reconstructs/redefines/reassigns an exported procedure every time that it (the ModuleApply) is called.¹ It does this so that the exported procedure's remember table will start from scratch each time that the ModuleApply is called.² So, the remember table is not causing any time reduction for multiple calls to the ModuleApply; it's only reducing the time for a single call. Thus there's no need to use forget to get a more-accurate measurement of the time for an iterated call to the ModuleApply.³

Footnotes:
[1] I realize now that I could've accomplished the same thing by using a forget inside the ModuleApply. The only benefit of that would be making the code easier to read.

[2] And that is done because it's the correct thing to do for the algorithm rather than because it makes timing measurement easier.

[3] That leaves the issue of measuring the time required for the garbage collection resulting from the final (and only the final) destruction of the remember table. Of course, this amount of time is independent of the number of iterations, and, in this case, it's very small.

For almost any time measurement in Maple (not just the case at hand), there's still the issue of measuring the time required for the overall final garbage collection (meaning all garbage, not just remember tables). This time is, in general, not small enough to be ignored. None of timing techniques discussed so far handle this (although Acer did discuss the issue itself at length a few Replies above this). I have some ideas about this that are worthy of a separate post (probably several separate posts).

@sand15 There was a major bug in the most-recent code that I posted---just a two-character difference between what I tested and what got copy-and-pasted into the post. I don't know how it happened. I corrected the code in the Reply. You must take the new code. The matrices produced by the old code were totally garbage.

@Carl Love This next entry is 2 to 3 times faster than the one immediately above, so, at this point, it is by far the speed champion among all the candidates tested. This one uses somewhat-sophisticated table and list operations and very little arithmetic.

NimMatrix:= proc(N::And(posint, Non(1)), K::posint)
local 
   i, j, 
   NK:= N^K,
   baseN:= table(
      [seq(0..NK-1)] 
      =~ [seq([seq(i)], i= Iterator:-MixedRadixTuples([N$K], 'compile'= false))]
   ),
   unbase:= table((rhs=lhs)~([entries(baseN, 'pairs')]))
;
   `mod`:= modp;             
    rtable(
      'symmetric', (1..NK)$2, 
      [seq([seq(unbase[baseN[i]+baseN[j] mod N], i= 0..j)], j= 0..NK-1)],
      'subtype'= Matrix
     )
end proc:

@Ritti Why do want Array output? And why do you want an Array so small, 11x11? I would make a 3-D plot, play around with some options until I was satisfied with it, then, maybe, extract an Array directly from my favorite plot. Try this for starters:

sol:-plot3d(x= 0..1, t= 0..1);

Your seq command was too far from acceptable syntax for me to figure out what you intended. What range of x do you want? What range of t?

No Maple-related question is too simple here. But next time put it in the Questions section rather than the Posts section. I've already moved this one.

@Ritti The command is pdsolve. See help page ?pdsolve,numeric.

What were you expecting the entries of the completed matrix to look like? Obviously they can't be numbers since you've not defined W or S. But if they're not numbers, what's the point of your evalf? Are you trying to set up some finite-difference equations?

To other readers: Yeah, I know that the proximate cause of the error is the failure to evaluate the derivatives before substituting numbers for the variables. I don't think that this OP could make use of that information before the questions above are addressed.

@digerdiga You sound as if you're upset that something that most users would consider a bug has been fixed. Do you not like it? I think that almost all elementary calculus instructors would consider the old behavior a bug. Note that conversion in the other direction (which seems more important to me) still works the same way:

convert(1/(1-x), FormalPowerSeries);

@mmcdara 

Here's a sleeker and more-optimized version of yesterday's module, still done with just arithmetic and list operations. I put this into your time-testing worksheet and it beat all the other methods. IIRC, it's a factor of 7 or 8 faster than my module from yesterday. Please test/confirm that.

NimMatrix:= module()
local
   P, N, NK, 
   ModuleApply:= proc(N::And(posint, Non(1)), K::posint)
   local i,j;
      thismodule:-N:= N;
      P:= N^~[$0..K-1];
      NK:= P[-1]*N;
      `mod`:= modp;
      baseN:= proc(n) option remember; local q:= n; ['irem(q, N, 'q')'$K] end proc;              
      rtable(
         'symmetric', (1..NK)$2, 
         [seq([seq(i &Nim j, i= 0..j)], j= 0..NK-1)], 
         'subtype'= 'Matrix'
      )
   end proc
;
export baseN, `&Nim`:= (a,b)-> inner(baseN(a)+baseN(b) mod N, P);             
end module:

The mysterious command inner in procedure `&Nim` is an undocumented built-in command that computes the inner product (aka dot product) of two lists as if they were vectors.

Why specifically do you want 4 iterations?

Your first integral is utterly trivial. Your second integral is very close to this simpler one (they only differ by a constant factor):

I3:= int(sin(n*x)*csc(x), x);

I haven't been able to get Maple to do that one. If someone else can get Maple to do it, nearly the same steps should work on your integral. If n is any specific integer, then Maple can do it. So, we just need a summation formula for sin(n*x) assuming n::integer.

@mmcdara 

You wrote:

• Right, it was only to say that we are not doing all the operations in Z/pZ (p being the base) but that some steps are done in an another base (in fact the base in which the elements of the matrices are written)

The correct operations are done in Z/pZ digit-wise (or element-wise). There is no "another base" that is relevant to this problem. You are confusing an abstract positive integer---which is independent of human culture and has no "base"---with a system for writing those integers---which is culturally dependent.

@mmcdara There you go again: saying that my answer "wasn't correct" and that I "had corrected an error"! And, no, it is not due to vagueness on your part about the carry rule. Tom was using my original code, which is based only on the algorithm stated in the 4 steps in the second paragraph of your original Question. The problem is that there's an error in your statement of those 4 steps.

I must emphasize that my original code wasn't correct due to some kind of default behavior. On the contrary, it's clear from the way that I sectioned the code that I expended extra effort to write it to perform the steps as you wrote them, even though I had some skepticism that that was how you intended them. That skepticism was due to mathematical intuition telling me that there's no serious mathematical significance to base 10, but it was ameliorated by the fact that people often post puzzle-type problems that do rely on a base-10 representation.

And don't go thinking that I'm one of those people who never admits to having made an error. The record here on MaplePrimes shows numerous times that I have admitted to making an error without the slightest bit of argument about it.

@mmcdara I did not "correct" anything! My original procedures correctly performed the operations that you incorrectly stated in the Question. It was only after my "probing" that I was able to deduce what the operations were that you actually intended. This was only a deduction of intentions; you still haven't anywhere in this thread made a complete and correct statement of the algorithm implied by your Question, although you do have some code that correctly performs it.

Your Question mentions "base 10" three times. This problem has nothing whatsoever to do with base 10. You'll notice that nowhere in any of the correct code is the number 10 used. The sentence that you used that leads to the most confusion is "do c = a+b just as if a and b were numbers in base 10." Think about what that sentence means when the target base is greater than 4 until you understand that my original code correctly performs that operation. See also my second Reply to Tom below.

Thank you for the timing code; I was curious.