results are not apparently deterministic? #15
Description
I am hunting down a bug that we have traced back to sedumi not being deterministic. I have a MWE:
sed_A = sparse([1e-06 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -0.000374569348444187 0 -0.000143510377232224 0 -0.000107308290246781 0 -0.00023475302385101 0 -0.000222588804655496 0 -0.00039621568504792 0 -0.000175372571085547 0 0 0 0 0 0 0 0;0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0;0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0;0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0;0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 0;0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -1 0 0 0 0 0 0 0 0 0 0 0 0;0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -1 0 0 0 0 0 0 0 0 0 0;0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -1 0 0 0 0 0 0 0 0;-2 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0;-2 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0;-2 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0;-2 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0;-2 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0;-2 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0;-2 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0;-2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 0 0 0 0 0 0 0 0;0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0.00182361766281337 0 0.000300035708922513 0 5.25148072155411e-05 0 0.000172937546376846 0 0.000368772505991557 0 0.000258802261860665 0 9.13124417751099e-05 0 -1 0 0 0 0 0 0;0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0.00166011586827782 0 5.08618097827969e-05 0 0.000550274603301129 0 -1.24577387791141e-05 0 2.80912803114481e-05 0 0.000787997869564677 0 0 -1 0 0 0 0 0;0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0.00131496023553193 0 -2.85427725918689e-05 0 -6.40917512673142e-05 0 -6.48347565119609e-05 0 -9.88411732133345e-05 0 0 0 -1 0 0 0 0;0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0.00116855302122233 0 -1.40653733430151e-05 0 1.38084332511408e-05 0 0.00052463330628182 0 0 0 0 -1 0 0 0;0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0.00177126319840008 0 0.000136498835240328 0 -0.000139615027512656 0 0 0 0 0 -1 0 0;0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0.00218208935736517 0 -0.000117739846758266 0 0 0 0 0 0 -1 0;0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0.00170708755797057 0 0 0 0 0 0 0 -1;-1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0]);
sed_b = [-5e-08;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0];
sed_c = [0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;1;0;0;0;0;0;0;0];
sed_K = struct(sprintf('f'), {0}, sprintf('l'), {17}, sprintf('q'), {[2 2 2 2 2 2 2 8]}, sprintf('r'), {0});
pars = struct(sprintf('fid'), {0}, sprintf('maxiter'), {100});
% run sedumi 200 times, and hash the output:
for i=1:200
[x,y,info] = sedumi(sed_A,sed_b,sed_c,sed_K,pars);
% get the md5 hash of x:
myhash = java.security.MessageDigest.getInstance('MD5');
myhash.update(typecast(x,'uint8'));
hstr = lower(sprintf('%02X',typecast(myhash.digest,'uint8')));
disp(hstr);
end
In any one Matlab instance, I tend to get the same results. In different Matlab instances, I can get different output. I have gotten all the following output hashes:
1347dafee66c8ff3680ff91ec51cc8bc
01b524f80080f1de14e910d6878ea380
1a8829b52cdf4e970f48ce4c2c0d5003
79f20e7f39ea5e1fba8c06f45d401960
and a few more. I have confirmed that the different hashes correspond to different output. Typically the variation is on the order of 1e-7, indicating some kind of single to double conversion might be at fault.
This is in Matlab r2007b on a linux machine. I have confirmed the results on a few diffferent linux machines all running r2007b. I have code which sets the random seed used by Matlab, and it does not appear to fix the issue. I have also tried setting maxNumCompThreads(1) to see if multithreading causes the problem. It does not appear to.
edit: I am using SeDuMi 1.21