2012/11/29 <[email protected]>: > Hi, Granfort, > > Currently I am implementing the BSBL-EM and BSBL-l1 algorithm by Zhang . The > effort is to maintain compatibility with the original calling conversion of > Zhang's TSP2012 paper. I am totally new to python and struggling in the > matrix/array conversion, matrix/array concatenate and insert etc., but I > enchanting at this programming language.
We try to avoid writing wrappers for external libraries when possible: - it makes it simpler for users to install the library - it makes it simpler for maintainers and users not to have to go through a complex nested class / function call structure when reading the code for debugging or understanding what's being computed: flat is better than nested: http://www.python.org/dev/peps/pep-0020/ The embedded liblinear and libsvm embedded in scikit-learn with their own wrappers are notable exceptions to this rule as their very mature implementations already used by a large portion of the machine learning community. > The insight of scikit-Learn was by an article on kaggle.com which interview > the winners of Merck visualization challenge by lvdm. I am not familiar with > the regression routines of sklearn, but I think once the code is thoughtfully > tested, maybe a wrapper on each function might do the job? We want to have as consistent as possible API and naming conventions for variable and class names across the scikit-learn code base. Hence we explicitly avoid single letter variable names from the mathematical expression of the original papers. The frequentist statistics, bayesian statistics, signal processing and machine learning literatures use inconsistent mathematical notations therefore we cannot reuse those as the would be confusing for people not familiar with those literatures. Thus we explicitly strive to use explicit descriptive names in plain English instead rather than greek letters and acronyms as often as possible (it not yet the case everywhere in the existing code base). scikit-learn is getting successful in part because we are trying hard to enforce those consistency rules to all the contributions to the code base. So before starting to code to contribute to the project you should really get familiar with the existing estimators, how they are implemented and so on. That being said is totally fine to code your own method in your own open source project on github with your own code conventions. Not everybody on earth has to follow our own design decisions :) -- Olivier http://twitter.com/ogrisel - http://github.com/ogrisel ------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net _______________________________________________ Scikit-learn-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/scikit-learn-general
