Scikit-learn: LabelBinarizer et LabelEncoder adaptent et transforment les signatures non compatibles avec Pipeline

Créé le 26 avr. 2014  ·  6Commentaires  ·  Source: scikit-learn/scikit-learn

J'obtiens cette erreur lorsque j'essaie d'utiliser LabelBinarizer et LabelEncoder dans un Pipeline :

sklearn/pipeline.pyc in fit_transform(self, X, y, **fit_params)
    141         Xt, fit_params = self._pre_transform(X, y, **fit_params)
    142         if hasattr(self.steps[-1][-1], 'fit_transform'):
--> 143             return self.steps[-1][-1].fit_transform(Xt, y, **fit_params)
    144         else:
    145             return self.steps[-1][-1].fit(Xt, y, **fit_params).transform(Xt)

TypeError: fit_transform() takes exactly 2 arguments (3 given)

Il semble que cela soit dû au fait que les signatures fit et transform des classes sont différentes de la plupart des autres estimateurs et n'acceptent qu'un seul argument.

Je pense que c'est une solution assez simple (il suffit de changer la signature en def(self, X, y=None) ) pour laquelle je serais heureux d'envoyer une pull request, mais je voulais vérifier s'il y avait d'autres raisons pour lesquelles les signatures sont les façon dont ils sont auxquels je n'ai pas pensé.

API

Commentaire le plus utile

Je vois qu'il y a eu beaucoup de réactions négatives sur cette page. Je pense qu'il y a eu un long malentendu sur le but de LabelBinarizer et LabelEncoder. Ce sont des cibles, pas des fonctionnalités. Bien qu'il soit vrai qu'ils ont été conçus (et mal nommés) avant mon époque.

Bien que je pense que les utilisateurs auraient pu utiliser CountVectorizer (ou DictVectorizer avec dataframe.to_dict(orient='records') si vous venez d'une base de données) à cette fin depuis longtemps, nous avons récemment fusionné un CategoricalEncoder (#9151 ) dans master, bien que cela puisse être intégré à OneHotEncoer et à un nouvel OrdinalEncoder avant la publication (#10521).

J'espère que cela satisfera les besoins d'une population clairement mécontente.

Je dois dire qu'en tant que personne qui consacre d'énormes quantités de temps libre au développement de ce projet depuis près de cinq ans maintenant (et a récemment été employé pour y travailler aussi), voyant l'ampleur des réactions négatives, plutôt que des contributions constructives à la bibliothèque est assez triste. Bien qu'il soit vrai que ma réponse ci-dessus selon laquelle vous devriez écrire une nouvelle chose de type Pipeline, plutôt qu'un nouveau transformateur pour les entrées catégorielles, était un malentendu de ma part (et aurait dû / aurait pu être corrigé par d'autres), ce qui, j'espère, est compréhensible tout en travaillant sur l'énorme charge de travail qui maintient ce projet.

Tous les 6 commentaires

Je pense que tu as raison de corriger ça.

Le 26 avril 2014 à 19h37, hxu [email protected] a écrit :

J'obtiens cette erreur lorsque j'essaie d'utiliser LabelBinarizer et LabelEncoder dans un
Pipeline:

sklearn/pipeline.pyc dans fit_transform(self, X, y, *_fit_params)
141 Xt, fit_params = self._pre_transform(X, y, *_fit_params)
142 if hasattr(self.steps[-1][-1], 'fit_transform'):--> 143 return self.steps[-1][-1].fit_transform(Xt, y, *_fit_params)
144 autres :
145 return self.steps[-1][-1].fit(Xt, y, *_fit_params).transform(Xt)
TypeError : fit_transform() prend exactement 2 arguments (3 donnés)

Il semble que cela soit dû au fait que les signatures d' ajustement et de transformation des

Je pense que c'est une solution assez simple (il suffit de changer la signature en def(self,
X, y=None)) pour lequel je serais heureux d'envoyer une pull request, mais je voulais
vérifier s'il y avait d'autres raisons pour lesquelles les signatures sont comme elles
sont auxquels je n'ai pas pensé.

-
Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps://github.com/scikit-learn/scikit-learn/issues/3112
.

Dans #3113, nous avons décidé que cela ne devait pas être corrigé car l'encodage des étiquettes n'appartient pas vraiment à un Pipeline .

@jnothman , juste pour savoir : que dois-je faire à la place si j'ai besoin de vectoriser une caractéristique catégorielle dans un pipeline ?

Vous feriez peut-être mieux d'écrire votre propre code Pipeline-like (en héritant peut-être de l'existant) pour gérer votre cas spécifique.

Au lieu d'utiliser LabelBinarizer dans un pipeline, je viens d'implémenter mon propre transformateur :

class CustomBinarizer(BaseEstimator, TransformerMixin):
    def fit(self, X, y=None,**fit_params):
        return self
    def transform(self, X):
        return LabelBinarizer().fit(X).transform(X)

Ça a l'air de faire l'affaire !

Éditer:

c'est une meilleure solution :
https://github.com/scikit-learn/scikit-learn/pull/7375/files#diff -1e175ddb0d84aad0a578d34553f6f9c6

Je vois qu'il y a eu beaucoup de réactions négatives sur cette page. Je pense qu'il y a eu un long malentendu sur le but de LabelBinarizer et LabelEncoder. Ce sont des cibles, pas des fonctionnalités. Bien qu'il soit vrai qu'ils ont été conçus (et mal nommés) avant mon époque.

Bien que je pense que les utilisateurs auraient pu utiliser CountVectorizer (ou DictVectorizer avec dataframe.to_dict(orient='records') si vous venez d'une base de données) à cette fin depuis longtemps, nous avons récemment fusionné un CategoricalEncoder (#9151 ) dans master, bien que cela puisse être intégré à OneHotEncoer et à un nouvel OrdinalEncoder avant la publication (#10521).

J'espère que cela satisfera les besoins d'une population clairement mécontente.

Je dois dire qu'en tant que personne qui consacre d'énormes quantités de temps libre au développement de ce projet depuis près de cinq ans maintenant (et a récemment été employé pour y travailler aussi), voyant l'ampleur des réactions négatives, plutôt que des contributions constructives à la bibliothèque est assez triste. Bien qu'il soit vrai que ma réponse ci-dessus selon laquelle vous devriez écrire une nouvelle chose de type Pipeline, plutôt qu'un nouveau transformateur pour les entrées catégorielles, était un malentendu de ma part (et aurait dû / aurait pu être corrigé par d'autres), ce qui, j'espère, est compréhensible tout en travaillant sur l'énorme charge de travail qui maintient ce projet.

Cette page vous a été utile?
0 / 5 - 0 notes