Closed schoffelen closed 4 years ago
This one replaces PR #14, which is a more elegant (and scalable) solution to taking the neighbours structures to a low-level (i.e. allowing for a potential speedup of the searchlight approach)
Hi @treder just pinging you about this. I was wondering whether you would be fine with merging this one? It allows for a computationally very efficient spatiotemporal searchlight (at least for naive_bayes as classifier), and it might be useful for the users. At the FT end I have some code to be deployed that relies on this PR.
Thanks, in the meantime however I found out that in my local fork I seem to be working in a differently named branch, sorry about that. I need to check which one is the functional one that interfaces nicely to fieldtrip
OK. I also need to come back to the FT tutorial but probably not before a few weeks from now. I also want to eventually retire the mv_crossvalidate function, it's been written before mv_classify existed and superfluous now, so it'd be good to get it out of the FT interface too (just replacing mv_crossvalidate by mv_classify should do the job).
Thanks. Well, I have already (at least in code) an updated tutorial, so perhaps most of that will be addressed in there, although I need to broadcast this to the outside world (just pinged you)
At the moment, it seems as if mv_crossvalidate is still used...
Were you planning to get rid of this function altogether?
Yes I'd like a minimal and easy interface for the end user, right now there's multiple classification functions with overlapping functionalities. I plan on completely removing mv_crossvalidate. Ideally mv_classify would be the only classification function (just like mv_regress is the only regression function) but mv_classify_across_time/timextime cover some frequent problems and are bit more efficient so will probably keep them.
Btw: does your code also work if cfg.cv = 'none'? The code branches off in this case (ll. 396+).
probably not, I'll check
…n classifier functions