En ce qui concerne les différences OrdinalEncoder
et la LabelEncoder
mise en œuvre , la réponse acceptée mentionne la forme des données: ( OrdinalEncoder
pour les données 2D; la forme (n_samples, n_features)
, LabelEncoder
est pour les données 1D: pour la forme (n_samples,)
)
C'est pourquoi un OrdinalEncoder
obtiendrait une erreur:
ValueError: Expected 2D array, got 1D array instead:
... si vous essayez de vous adapter aux données 1D: OrdinalEncoder().fit(['a','b'])
Cependant, une autre différence entre les encodeurs est le nom de leur paramètre appris ;
LabelEncoder
apprend classes_
OrdinalEncoder
apprend categories_
Notez les différences dans l'ajustement LabelEncoder
vs OrdinalEncoder
, et les différences dans les valeurs de ces paramètres appris. LabelEncoder.classes_
est 1D, tandis que OrdinalEncoder.categories_
2D.
LabelEncoder().fit(['a','b']).classes_
# >>> array(['a', 'b'], dtype='<U1')
OrdinalEncoder().fit([['a'], ['b']]).categories_
# >>> [array(['a', 'b'], dtype=object)]
D'autres encodeurs qui fonctionnent en 2D, notamment OneHotEncoder
, utilisent également la propriétécategories_
Plus d'informations ici sur le dtype <U1
(little-endian, Unicode, 1 octet; c'est-à-dire une chaîne de longueur 1)
ÉDITER
Dans les commentaires de ma réponse, Piotr n'est pas d'accord ; Piotr souligne la différence entre l' encodage ordinal et l' encodage d' étiquette plus généralement.
- Le codage ordinal sont bonnes pour les variables ordinales (où les questions d'ordre, comme
cold
, warm
, hot
);
- vs une variable non ordinale (alias nominale ) (où l'ordre n'a pas d'importance, comme
blonde
, brunette
)
C'est un excellent concept, mais cette question porte sur les sklearn
classes / implémentations. Il est intéressant de voir comment l'implémentation ne correspond pas aux concepts; surtout OrdinalEncoder
; spécifiquement comment vous devez faire l'encodage ordinal vous-même .
En ce qui concerne la mise en œuvre il semble que LabelEncoder
et OrdinalEncoder
avoir un comportement cohérent dans la mesure où les nombres entiers choisis . Ils attribuent tous deux des nombres entiers par ordre alphabétique . Par exemple:
OrdinalEncoder().fit_transform([['cold'],['warm'],['hot']]).reshape((1,3))
# >>> array([[0., 2., 1.]])
LabelEncoder().fit_transform(['cold','warm','hot'])
# >>> array([0, 2, 1], dtype=int64)
Remarquez comment les deux encodeurs ont attribué des entiers dans l'ordre alphabétique «c» <«h» <«w».
Mais cette partie est importante: notez comment aucun codeur n'a obtenu l'ordre "réel" correct (c'est-à-dire que l'ordre réel doit refléter la température, où l'ordre est 'froid' <'chaud' <'chaud'); sur la base d'un ordre "réel", la valeur 'warm'
aurait été affectée à l'entier 1.
Dans le blog référencé par Piotr , l'auteur n'utilise même pasOrdinalEncoder()
. Pour réaliser le codage ordinal, l'auteur le fait manuellement: mappe chaque température à un entier d'ordre "réel", en utilisant un dictionnaire comme{'cold':0, 'warm':1, 'hot':2}
:
Reportez-vous à ce code à l'aide de Pandas, où nous devons d'abord attribuer l'ordre réel de la variable via un dictionnaire ... Bien que ce soit très simple, mais il nécessite un codage pour indiquer les valeurs ordinales et quel est le mappage réel du texte à l'entier selon l'ordre.
En d'autres termes, si vous vous demandez si vous souhaitez l'utiliser OrdinalEncoder
, veuillez noter OrdinalEncoder
qu'il se peut que le «codage ordinal» ne soit pas fourni comme vous l'attendez !
OrdinalEncoder
?