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?