Hi Scikit-Learn fellas,
Here is my request for comments and contributions: as I have briefly presented
to Gael at OHBM, we (with Matteo, CCed) initiated a new project --
DueCredit to enable users quickly harvest necessary citations for the methods
and software they have used in their analyses.
E.g. here is a quick demo output from running a portion of unittests of PyMVPA
(ATM requires patched pymvpa [1] to get PyMVPA references, but sklearn should
be there even if you try with stock pymvpa -- read below why)
$> python -m duecredit /usr/bin/nosetests mvpa2.tests.test_transerror
........
DueCredit Report:
- libsvm (v None) [1]
- mvpa2 (v 2.4) [2]
- mvpa2.clfs.SVM (v 2.4) [3]
- mvpa2.clfs.smlr:SMLR (v 2.4) [4]
- mvpa2.clfs.transerror:_call (v 2.4) [5]
- mvpa2.featsel.rfe:_train (v 2.4) [6]
- mvpa2.measures.searchlight:_call (v 2.4) [7]
- scipy (v 0.14.1) [8]
- sklearn (v 0.16.1) [9]
- sklearn.ensemble.forest:RandomForestClassifier.predict_proba (v 0.16.1) [10]
- sklearn.tree.tree:DecisionTreeClassifier.predict_proba (v 0.16.1) [11]
4 packages cited
1 modules cited
6 functions cited
References
----------
[1] Chang, C.-C. & Lin, C.-J., 2011. LIBSVM. ACM Trans. Intell. Syst. Technol.,
2(3), pp.1–27.
[2] Hanke, M. et al., 2009. PyMVPA: a Python Toolbox for Multivariate Pattern
Analysis of fMRI Data. Neuroinform, 7(1), pp.37–53.
[3] Vapnik, V., 1995. The Nature of Statistical Learning Theory, New York:
Springer.
...
Then later those all references could also be exported as a bibtex:
> duecredit summary --format=bibtex
@article{Hanke_2009, title={PyMVPA:....
@article{pedregosa2011scikit, ...
@article{Kriegeskorte_2006, title={...
...
and we hope to support even more formats to simplify citations even further
(e.g. latex + bibtex combo ;) )
As we have outlined in README:
https://github.com/duecredit/duecredit/#duecredit-101 there are two ways how to
provide citations:
1. natively within the code base (that is what we have done to PyMVPA in [1]).
Idea is that such "native support" should not impact original project to
any degree -- duecredit dependency would remain optional and code must not
puke
if something in duecredit fails
2. and through "injections" -- decorating corresponding functions upon
corresponding
module import, that is what we have done so far
for some references within numpy, scipy, scikit-learn.
Ideally I see projects themselves adopt the 'native' approach (so we
scale and don't impose any notable runtime impact associated with injections
mechanism) but I understand that it might be a while and opinions might vary,
so it might be that injections mechanism will stay forever.
Meanwhile I would like to hear your feedback
- would you be interested to adopt duecredit natively in scikit-learn
eventually (I know Gael's opinion already ;) )?
and contributions
- if not natively -- I would appreciate PRs for injections to
scikit-learn[2] or any other module to get your or others work cited.
If interested, here is my brief lightning talk at debconf a week ago
http://caesar.acc.umu.se/pub/debian-meetings/2015/debconf15/Lightning_talks_3.webm
scroll to around 43rd min
duecredit is on github: https://github.com/duecredit/duecredit/
and pypi: https://pypi.python.org/pypi/duecredit
[1] https://github.com/PyMVPA/PyMVPA/pull/330
[2]
https://github.com/duecredit/duecredit/blob/master/duecredit/injections/mod_sklearn.py
--
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Research Scientist, Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
------------------------------------------------------------------------------
_______________________________________________
Scikit-learn-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/scikit-learn-general
