2012/1/16 Mathieu Blondel <[email protected]>: > On Mon, Jan 16, 2012 at 10:29 PM, Olivier Grisel > <[email protected]> wrote: > >> +1 for going on with the merge of ndarray / sparse matrix implementations. > > +1. When you have abstract code that is representation-independent, > being able to use the same estimator transparently is a real comfort. > >> However that won't solve the fact that some estimators are array only >> implementations and it could be would be very for client code e.g. >> nltk to be able to instrospect if estimators instances and classes >> have special capabilities, esp. in terms of accepted input >> representations. > > +1, I wanted to say the same. > >> I agree that we should take care of not drowning the scikit-learn code >> base into frameworkish boiler plate. We could still make those >> annotation optional and assume that if no annotation is given then >> only arrays are accepted as input. > > The thing which I'm worried about with the decorator solution (as > opposed to my hackish solution) is that some people may forget to > annotate their user-land estimators...
Then let me rephrase that last sentence: We could still make those annotations optional and assume that if no annotation is given then only arrays are *expected* to be accepted as input. Also, if we implement the static `accept_input` declaration, that would allow us to improve and more more generic the check input helpers using a common API `check_input(estimator, input_args*, input_kwargs**)` that would take care of most of the common cases. -- Olivier http://twitter.com/ogrisel - http://github.com/ogrisel ------------------------------------------------------------------------------ RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 _______________________________________________ Scikit-learn-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/scikit-learn-general
