@Markiyan Hirnyk 

I cannot edit the last Reply, which MaplePrimes really messed up. Trying the upload again.

Download convertDiff.mw

@Markiyan Hirnyk 

Agreed, it is untidy.

In your transcription of the example at ?convert,diff , you missed the [2] in the last term.

Here is what the OP meant as input (although I don't know whether he will be pleased with the voluminous output).

Download convertDiff.mw

@Markiyan Hirnyk In your first example, f is a function of two variables, and you have not specified the variables with respect to which to take its derivatives. Perhaps such a situation should generate an error message. Regardless, the situation is different than the one the OP is asking about, for which convert(..., Diff) does work fine.

In your second example, D1 is just a meaningless symbol to Maple.

In your third example, the convert(..., Diff) works fine for me. You might need to do a restart; it seems as if f is already defined for you.

@Markiyan Hirnyk Your test range is too small to detect the difference. The differences that you are seeing are just noise. Try this

CodeTools:-Usage({seq(13^k mod 100, k= 1..100000)}):
memory used=4.32GiB, alloc change=9.37MiB, cpu time=41.67s, real time=41.34s

CodeTools:-Usage({seq(13 &^ k mod 100, k= 1..100000)}):
memory used=8.40MiB, alloc change=0 bytes, cpu time=157.00ms, real time=143.00ms

@Kitonum Note the difference in efficiency between 13^k mod 100 and 13 &^ k mod 100.

@J4James That's the point of the exercise: contrast. Procedures and expressions are different. In eval(f), the x is a procedure parameter, and it is not affected by the assignment to global x.

The presence of a subscript is insignificant. You'll get the same error if you use just P^q+R^q.

@Durre 

1. There is no practical difference between evalf(Int(...)) and int(..., numeric). I think that the former is the more common usage.

2. I picked _d01ajc because the help said that it was for badly behaved integrands. I guess if _d01akc works, you can use it.

@Joe Riel I thought that he meant 4 groups with 7 members each.

@Luka A vector can be considered a 1 x n matrix.

Only square matrices have eigenvectors, but the eigenvectors themselves are not square.

@brian bovril As long as the number of groups is a power of two, the divide-and-conquer approach will work. It doesn't matter what the number of numbers is.

@Andriy 

The time savings effected by the various ways of declaring the Matrix are minuscule compared with the time taken by elem. Thus the measurement of those savings is lost in the "noise" of the measurement of the overall time. As shown in an example at ?Fortran_order , the savings from scanning a 2000 x 2000 Matrix in the correct order is slightly less than 0.1 s. Thus the savings from scanning a 500 x 500 Matrix in the correct order wouldn't even be measurable. The smallest measurable time in Maple is 1/64 s.

@Andriy Agreed on all points. I can see that you already have much understanding of these matters.

What is the data type of the entries? (integer, rational, float, polynomial, etc.)

How much savings are you getting (in percentage real time) by using Threads? The sequential code to compare with is not your original loops, but rather the automatic fill

st:= time[real]():  A:= Matrix(N, N, elem, shape= symmetric):  time[real]()-st;

And what is your value of kernelopts(numcpus)?

@brian bovril 

Rather than altering the code, it is easy to do the labeling with post-processing:

L:= [1829.0, 1644.0, 1594.0, 1576.0, 1520.0, 1477.0, 1477.00, 1404.0
      , 1392.0, 1325.0, 1313.0, 1297.0, 1292.0, 1277.0, 1249.0, 1236.0]:
Labels:= [A||(1..nops(L))]:
L_ind:= Var(L, 4, 4): #Call Joe's procedure
subsindets(L_ind, posint, k-> L[k]);
              [[1829.0, 1392.0, 1292.0, 1249.0],
                [1644.0, 1576.0, 1277.0, 1236.0],
                [1594.0, 1477.0, 1325.0, 1313.0],
                [1520.0, 1477.00, 1404.0, 1297.0]]

subsindets(L_ind, posint, k-> Labels[k]);
 [[A1, A9, A13, A15], [A2, A4, A14, A16], [A3, A6, A10, A11],
   [A5, A7, A8, A12]]

@Andriy Sorry, I forgot the angle brackets. Change the second-to-last line to

A[i,..]:= < Threads:-Seq(Elem(i,j), j= 1..N) >

(I corrected the original.)

In your real code, is elem also something trivial, timewise?