Intel® oneAPI Math Kernel Library
Ask questions and share information with other developers who use Intel® Math Kernel Library.
6998 Discussions

mkl_sparse_?_ev convergence tolerance issue (?)




i will post a testcase in the next few days, just busy preprocessing PPMI data right now.


the issue is this: when i specify fpm[1] = 14 (i.e. convergence tolerance of 10^{-14+1}), the solver does not seem to complete in a reasonable time.


in MATLAB, the default convergence tolerance is 10^-14 so i am a little surprised by this. the convergence issue with mkl_sparse_?_ev can be easily reproduced using my previous test case given here.


the next issue, which is probably related to some issue with mkl_sparse_?_ev being unable to complete within 24 hours for 10^-14 tolerance (on any matrix we've tried), is that when the tolerance is set to 10^-13, the output is wrong.


i have a matrix that works in MATLAB and produces the expected output, whereas for mkl_sparse_?_ev, it fails to produce the visually-equivalent output. 


i will be providing a test case of the matrix in both the MKL CSR format, and the coordinate format that can be used by MATLAB's "spconvert" function, and input into their 'eigs' function with the 'smallestreal'


i suspect the team hasn't had many requests about mkl_sparse_?_ev, since the convergence tolerance is very high. if MATLAB is using 10^-14 by default, MKL should use something similar. many people will 'mock up' their solution in MATLAB and proceed to write it in C.


testcase coming soon, i promise.

0 Kudos
2 Replies



M.txt.rar - original matrix in CSR format.

jM.txt.rar - original column indices array for CSR matrix

iM.txt.rar - original row indices array for CSR matrix

M.coord.mat.rar - matlab-converted version of M matrix, which can be used directly with 'eigs':

note: as in the previous test case: M.txt and jM.txt are binary files!

in case you're lazy use:

  • to read the number of rows and elements from iM.txt, where the remaining entries of iM.txt are the entries of iM


iMfileptr = fopen("iM.txt", "r")
fscanf(iMfileptr, "%d\t%d\t", &nrRows, &nrElements);
MKL_INT *iM, *jM;
double *M;
iM = (MKL_INT*) mkl_calloc(nrRows+1,sizeof(MKL_INT),32);
    for(MKL_INT i=0; i<nrRows;i++)
        fscan(iMfilePtr, "%d\t", iM[i]);
    iM[nrRows] = nrElements + 1;
M = (double*) mkl_calloc(nrElements, sizeof(double), 32);
jM = (MKL_INT*) mkl_calloc(nrElements, sizeof(MKL_INT), 32);
//read M
FILE * fptr = fopen("M.txt", "r");
fread(&M, sizeof(double), iM[nrRows], fptr);
//read jM
FILE *fptr2 = fopen("jM.txt", "r");
fread(&jM, sizeof(MKL_INT), iM[nrRows], fptr2); 



anyways, it turns out after using a better 'rcond' for my local optimisation, mkl_sparse_?_ev produces the expected output.


since i made the post i figured i'd follow through and give you guys the stuff, just because it's good to have some test cases.


solver takes longer than i'd like, but i can't complain with what i'm seeing. wow did optimising my rcond really change things.


0 Kudos

sample output


stuff on the exterior early on is calibration, some movement, but a few frames in (starting around ~0:05) you really see what block design fMRI is about.


look at those activations. they're really popping now. this is what block design fMRI is all about. isolating the theorised mechanisms by administering a collection of stimuli hypothesised to induce them.


dunno how many times i can body loltman and all these pretenders. if they only wanted to do real machine learning, which no one does because it's hard af.


anyone remember weka? feels like those days are neigh with all these toolboxes. hiding from the math, clicking a few buttons in a GUI, expecting to make a difference. give me a break.


0 Kudos