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... Mathieu ------------------------------------------------------------------------------ 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
