If, however, what you intend to have is a permutation matrix, you can store it as a permutation vector (i.e., a 1-D array), with values [1, 4, 2, 3, 5], where the entries are the row numbers of the one (and only one) element with value = 1 in each column, with zeros in the rest of the column.

Such permutation vectors are routinely used in Lapack for routines that do Gaussian elimination with pivoting.

If you want something else, you need to describe that in more detail.

Last edited by mecej4 on Thu Aug 10, 2017 4:20 am; edited 1 time in total

If what you wish to do is to work with only the non-zero entries in a sparse matrix, you can choose a sparse matrix representation that suits your needs.

The simplest is the so called COO representation. See, for example, http://www.culatools.com/blog/2011/09/08/sparse-101-matrix-formats/ .In this representation, the sparse matrix is stored as an NNZ X 3 matrix, where NNZ is the number of non-zero elements. Each row of the compact matrix contains the (R, C, V) triplet for a non-zero element of the original matrix. R and C are the coordinates (row and column) and V is the value of the matrix element in that position. Except in a few special cases, there are no entries in the COO representation with V = 0.

Viroxa, your phrase "what I want is exactly like this" reminded me of a poster that I saw decades ago, which said:

Quote:

Engineers Do Precision Guesswork

Last edited by mecej4 on Thu Aug 10, 2017 1:13 pm; edited 1 time in total

mecej4's pivot array, and his sparse matrix representation are both great ideas, but if the initialisation is done once per run of the program, the DATA statement (with all the values including zeroes) takes a lot of beating. 14x7 is 98 elements, and as the values are 0, 1 ... etc but never very big, even INTEGER*4 takes up less than 400 bytes, so it is difficult to see that there is a lot of benefit. Traditionally, a lot of such initialisations could be done in a BLOCK DATA subprogram. You could use INTEGER*2.

I've never been very fond of BLOCK DATA, probably because many compilers I've used don't support it rather than it being disapproved of in modern Fortran.

If the array needs to be reinitialised after it has been changed, DATA and BLOCK DATA won't do the job unless you keep a set of arrays in pristine form and simply copy them into your working arrays each time reinitialisation is called for.

Something similar happens with a Multiple Document Interface (MDI) Windows program, because each 'document' (i.e. problem running separately) may need its own initialisations. In such a case, where the program space requirements do not stress the available memory capacity, I find it better to spawn a new complete copy of the program rather than having child windows. That also solves problems of having unique datasets for each 'document'.

... if the initialisation is done once per run of the program, the DATA statement (with all the values including zeroes) takes a lot of beating

If the program is intended to be applied to more than one problem, fixed arrays initialised with DATA statements are not suitable. Read the problem data from a file, calculate the array sizes based on that data, allocate the arrays, and then read problem data into the arrays (or, if possible, populate the arrays using an algorithm). This is far better than writing an inflexible program to solve only one problem size, and then attempting to adapt the program to each new problem size that comes up.

Read the problem data from a file, calculate the array sizes based on that data, allocate the arrays, and then read problem data into the arrays (or, if possible, populate the arrays using an algorithm)

That's the way I did it.

One more question regarding sparse matrices:
Are there intrinsic routines for sparse matrix operations or could you recommend a library to use?

Read the problem data from a file, calculate the array sizes based on that data, allocate the arrays, and then read problem data into the arrays (or, if possible, populate the arrays using an algorithm)

That's the way I did it.

One more question regarding sparse matrices:
Are there intrinsic routines for sparse matrix operations or could you recommend a library to use?

Mecej4, have you try his methods in comparison with ones of INTEL and LAIPE we tried earlier this year? Both Intel and LAIPE sparse solvers were slower then dense INTEL solver for the same sparse matrices.

Dan, most of the sparse matrix packages are intended for application to matrices other than banded matrices. It can certainly be the case that, for a banded matrix, a specialized band matrix solver will be a better choice than packages such as UMFPack, SuperLU, MUMPS and WSMP. The packages that I listed are of real help with other matrix sparse patterns, such as those that come from piping networks, product manufacturing and distribution, airline reservations, etc.

Laipe2 may well be better for some types of matrices, but I did not like the Fortran 77 tricks that Jenn-Ching Luo uses in his compact matrix representation. Nobody else uses those tricks and they will give you trouble with modern Fortran. For many users, it can be a big hurdle to have to convert from one of the standard compact storage conventions to the Laipe2 scheme.

The only software from Saad's site that I actually used was for converting from one sparse format to another, e.g., RUA to CSR.