Back to the main page.
Bug 1943 - identify channel function in ft_databrowser does not yield correct channel
| Status | CLOSED FIXED |
| Reported | 2013-01-23 10:39:00 +0100 |
| Modified | 2014-03-12 12:21:42 +0100 |
| Product: | FieldTrip |
| Component: | plotting |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P3 major |
| Assigned to: | Jörn M. Horschig |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: | http://bugzilla.fcdonders.nl/show_bug.cgi?id=1431http://bugzilla.fcdonders.nl/show_bug.cgi?id=1481http://bugzilla.fcdonders.nl/show_bug.cgi?id=498 |
Eelke Spaak - 2013-01-23 10:39:35 +0100
On the mentat nodes (or through torque), when I use the identify-function of the databrowser and click on a channel trace, most of the time the wrong channel is highlighted. This can be reproduced by databrowsing any CTF275 dataset (at least any of mine).
Eelke Spaak - 2013-01-23 13:51:52 +0100
Created attachment 411 test data (and empty cfg) to reproduce bug
Robert Oostenveld - 2013-01-23 16:28:36 +0100
an easy demonstration >> nearest([1:10] * 1e-9, 10*1e-9) ans = 1 this should have returned 10.
Robert Oostenveld - 2013-01-23 16:29:23 +0100
(In reply to comment #2) oh, I should have mentioned that Diego traced this down to the nearest function being applied to fT (i.e. 10^-12) magnitude values.
Robert Oostenveld - 2013-01-23 16:51:29 +0100
there was a fixed rounding off at 10^6 decimals, I changed that into a relative rounding off. For time and frequency axesfor which it was designed it should still work as before raspberry> svn commit nearest.m Sending nearest.m Transmitting file data . Committed revision 7397.
Robert Oostenveld - 2013-01-23 16:52:36 +0100
These now both work fine >> nearest([1:10] * 1e-9, 8*1e-9) ans = 8 >> nearest([1:10] * 1, 8) ans = 8
Martin Vinck - 2013-05-17 11:47:40 +0200
There's large errors involved with the nearest function caused by the precision operation in line 136 Take for example x = 0:492:(492*(25*10^7)) y = 8424306*492 indx = nearest(x,y) % indx = 8424183 indx2 = find(x<=y, 1, 'last); % indx2 = 8424307
Martin Vinck - 2013-05-17 11:52:56 +0200
(In reply to comment #6) besides the fact that the function doesn't do at all what it's supposed to do, it can also be implemented way faster on sorted arrays using find(x<=y, 1, 'last') and find(x>=y, 1, 'first') and comparing these.
Robert Oostenveld - 2013-05-17 12:59:52 +0200
(In reply to comment #7) it is doing correctly what it was designed to do according to the test_nearest.m script. Could you add this case to that test script?
Robert Oostenveld - 2013-05-17 13:25:19 +0200
(In reply to comment #7) the x<=y might be a neat trick to avoid the error accumulation that was observed by Craig in bug 498.
Martin Vinck - 2013-05-17 13:27:15 +0200
(In reply to comment #8) done
Martin Vinck - 2013-05-17 13:29:19 +0200
(In reply to comment #9) in that case, you first have to sort the array. the you do find(array<=val, 1, 'last') and find(array>=val,1, 'first') and compare these two to find the nearest one. for computational speed you can first do if ~issorted(array) [array, origindx] = sort(array); end then later transform back via origindx. but sort will still be much faster than doing the min(abs( of the difference
Martin Vinck - 2013-05-17 13:29:53 +0200
(In reply to comment #11) usually the arrays are sorted, in any case
Martin Vinck - 2013-05-18 10:38:48 +0200
(In reply to comment #12) As far as I can see (there might be some older Matlab versions that don't support this), using this strategy with sort and find, the function could also support other datatypes than real, e.g. uint64. Sort works on these, and find also.
Robert Oostenveld - 2013-05-18 12:18:15 +0200
(In reply to comment #13) data types are another good reason to use < and > rather than minus. Given http://fieldtrip.fcdonders.nl/code_guidelines#ensure_that_it_runs_on_older_matlab_versions it does not have to run on very old versions. I checked matlab2008a and 2006a and this works: >> x = 1:10 x = 1 2 3 4 5 6 7 8 9 10 >> find(x<3, 1, 'first') ans = 1 >> find(x<3, 1, 'last') ans = 2 we don't have to consider older versions.
Jörn M. Horschig - 2013-09-25 10:23:11 +0200
Diego, I hope you don't mind that I took this one, but it's in light with test_nearest failing that I started working on yesterday: I implemented Martin's suggestion for nearest: wassorted = true; if ~issorted(array) wassorted = false; [array, xidx] = sort(array); end indx2 = find(array<=val, 1, 'last'); indx3 = find(array>=val, 1, 'first'); if abs(array(indx2)-val) <= abs(array(indx3)-val) indx = indx2; else indx = indx3; end if ~wassorted indx = xidx(indx); end I chose to give precedence to the lower value (hence <= in the if statement) because otherwise test_bug2220 crashes (the old nearest implementation behaved that way, see bug 498), but this is really an arbitrary choice. I ran some other test scripts, which all passed. svn ci utilities/nearest.m -m "bugfix #1943 - nearest now works using find rather than on absolute differences weighted by some precision matrix" Sending utilities/nearest.m Transmitting file data . Committed revision 8534.