Неверный размер вектора OneHotEncoder в pyspark
Я попытался проверить вывод OneHotEncoder в pyspark. Я читал на форумах и в документации кодировщика, что размер закодированного вектора будет равен количеству различных значений в кодируемом столбце.
from pyspark.ml.feature import OneHotEncoder, StringIndexer
df = sqlContext.createDataFrame([
(0, "a"),
(1, "b"),
(2, "c"),
(3, "a"),
(4, "a"),
(5, "c")
], ["id", "category"])
stringIndexer = StringIndexer(inputCol = "category", outputCol = "categoryIndex")
model = stringIndexer.fit(df)
indexed = model.transform(df)
encoder = OneHotEncoder(inputCol = "categoryIndex", outputCol = "categoryVec")
encoded = encoder.transform(indexed)
encoded.show()
Ниже приведен результат приведенного выше кода.
+---+--------+--------------+-------------+
| id|category|categoryIndex| categoryVec|
+---+--------+--------------+-------------+
| 0| a| 0.0|(2,[0],[1.0])|
| 1| b| 2.0| (2,[],[])|
| 2| c| 1.0|(2,[1],[1.0])|
| 3| a| 0.0|(2,[0],[1.0])|
| 4| a| 0.0|(2,[0],[1.0])|
| 5| c| 1.0|(2,[1],[1.0])|
+---+--------+--------------+-------------+
Согласно интерпретации столбца categoryVec, размер вектора равен 2. В то время как количество различных значений в столбце «category» равно 3, то есть a, b и c. Пожалуйста, позвольте мне понять, что мне здесь не хватает.
Ответы 1
Из документов для pyspark.ml.feature.OneHotEncoder:
class pyspark.ml.feature.OneHotEncoder(dropLast=True, inputCol=None, outputCol=None)A one-hot encoder that maps a column of category indices to a column of binary vectors, with at most a single one-value per row that indicates the input category index. For example with 5 categories, an input value of 2.0 would map to an output vector of [0.0, 0.0, 1.0, 0.0]. The last category is not included by default (configurable via dropLast) because it makes the vector entries sum up to one, and hence linearly dependent. So an input value of 4.0 maps to [0.0, 0.0, 0.0, 0.0].
Таким образом, для категорий n у вас будет выходной вектор размера n-1, если вы не установите dropLast на False. В этом нет ничего плохого или странного - вам нужны только индексы n-1 для однозначного сопоставления всех категорий.