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

@Kitonum How can there be two answers?

@Mac Dude You can "pin" it by clicking on the box of stars in upper right corner of the post, immediately under the box with the "thumb up" where the votes are recorded. This saves it to your list of favorites which can be accessed from your profile.

I edited the tags in your post, hoping that Edgardo would notice.

Maple 17 is a software package, the current version of Maple. MaplePrimes is this forum that we are posting on, where Maple and related packages are discussed.

There is a constant Pr in the second equation. I assumed that this was a typo for Pi. Using that and attempting to solve the system, I get the dreaded error "Newton iteration is not converging".

@Murilo V The multiplication operator was likely caused by typing an extra space between evalf and its opening parenthesis. This only affects 2D input.

@kamrul126 Does the file exist already? If it does, then that is the problem. Do you have write permission for the directory/folder specified by currentdir()? If you are not sure, try using a fully qualified file name such as "C:/Users/Carl/Desktop/file1.mpl"

@DJJerome1976 asked:

If I change the problem to 2*sin(2*x+Pi/4), and the desired form is sqrt(2)*sin(2*x)+sqrt(2)*cos(2*x), expand(,trig) no longer works for me. How might this one be tackled? Clearly, one may just replace "x" with "2x," but is this the only way?

combine(expand(%));

@Markiyan Hirnyk My comment was directed to the OP.

@Markiyan Hirnyk Isn't that close enough to the desired output to count? Is the problem that you want the sqrt(2) in the front?

This output can be obtained with a simple expand; the trig modifier is unnecessary.