Back to the main page.

Bug 1759 - ft_apply_montage: sparse matrix multiplication leads to different results than full matrix multiplication

Status CLOSED WONTFIX
Reported 2012-10-01 16:27:00 +0200
Modified 2014-03-12 12:21:38 +0100
Product: FieldTrip
Component: core
Version: unspecified
Hardware: PC
Operating System: Windows
Importance: P3 minor
Assigned to: Jörn M. Horschig
URL:
Tags:
Depends on:
Blocks:
See also:

Jörn M. Horschig - 2012-10-01 16:27:21 +0200

I was looking whether there were some discrepancies between ft_megplanar and the way I am doing planar gradient transformation in the online neurofeedback experiment. I found some, and after a while figured that the sparse representation of the tra matrix is causing this. In line 288 ff. of ft_apply_montage, it is doing something like: if isa(data.trial{i}, 'single') % sparse matrices and single precision do not match data.trial{i} = full(montage.tra) * data.trial{i}; else data.trial{i} = montage.tra * data.trial{i}; end I found this: >> onlinedata{1} = sparse(planarmontage.tra)*data.trial{1}; >> onlinedata{2} = planarmontage.tra*data.trial{1}; >> sum(sqrt((onlinedata{1}(:)-onlinedata{2}(:)).^2)) ans = 1.0230e-024 A reason to worry? It's still ~10 orders of magnitude smaller than the signal itself (e-14). I wonder which version is more correct?


Robert Oostenveld - 2012-10-01 16:44:00 +0200

(In reply to comment #0) Both suffer from numerical inaccuracies. Them being different suggests that 0*x is not exactly 0 in the full representation. For the sparse representation the multiplication with 0 is not performed. I suggest you make a test script out of it (with the data in a small mat file). If you then check the size not as sum(...) but mean(...) and perhaps do abs instead of taking the square, we would have an impression if it is in the order of eps relative to the actual numbers.


Jörn M. Horschig - 2012-10-01 17:06:21 +0200

of course I checked the zero-elements, they are all fine. If I do (x!=0) - (y!=0), it's alright but I'm gonna make a testscript to check. actually, the endresults (topos) look very similar, that's why I set this bug to 'minor'


Jörn M. Horschig - 2012-10-01 17:06:41 +0200

(In reply to comment #2) ery similar = exactly the same


Jörn M. Horschig - 2012-10-24 10:59:27 +0200

K>> test_bug1759 ans = 1.3194e-030 which is mean(abs(...)) I guess this is a won't fix?


Jörn M. Horschig - 2012-12-12 10:25:22 +0100

using the identical function, I changed the testscript: assert(identical(tmp{1}, tmp{2}, 'reltol', 0.0001)); A relative tolereance of 0.0001, meaning 0.1 promille should be conservative enough to verify that this is not an issue