Sequential Feaute Selection CPU utilization

[whalebot-helmsman]

For multiple CPU utilization SFS uses sklearn.model_selection.cross_val_score. It runs one process per validation fold. Usually there are more features than folds. So, it is more scalable to use one process per feature.

[rasbt]

I agree, in typical use cases the number of features should be larger than the number of folds in CV, so the multiprocessing should run over the features not the folds. This should be relatively easy to change via the multiprocessing submodule or mputil, will take a look at that some time

[whalebot-helmsman]

I want to make this enchancement, but unit test failed on my laptop #192

[rasbt]

Thanks for working on it. How did the unittests fail? Maybe just submit a PR and I could take a look! :)

[whalebot-helmsman]

CPU per feature implementation gives results for various n_jobs, test.py in same gist.
Also, I added same parallel technique for exhaustive feature selection.

I can create new pull request today after fixing "Can't pickle <class 'method'>" for older pythons

[rasbt]

Thanks! I am looking forward to the PR and be happy to give you some feedback then.

I can create new pull request today after fixing "Can't pickle <class 'method'>" for older pythons

Which versions of Python would that be? Currently, the package supports the latest 2.7 version, 3.5, and 3.6. Is any of these causing problems? In general, if older Python versions (e.g., 2.6, 3.3, 3.4) work, that's nice, but I wouldn't make backwards compatible changes to support these if it adds to the code complexity

[whalebot-helmsman]

I met this problem on python 3.3.2. This is CentOS 6.7, kind of a target platform for me and system with 64 CPUs. Thats why it is so important.

There is two ways to fix this. None of them adds much to code complexity.
Fisrt, move SQS._calc_score to free-standing(non-member) function.
Second, add free-standing(non-member) function wrapper for SQS._calc_score.

I like first one more.