The purpose of one-hot encoding is to binarize categorical labels so that your model doesn't learn a spurious ordinal relationship.
For example if you had categories
Blue, it would be bad to encode
Red as 0,
Yellow as 1, and
Blue as 2 because your model might accidentally "learn" that Red < Yellow < Blue. In this case you should use one-hot encoding.
But for some categorical features, an ordinal encoding makes sense. For example, your dataset has the feature "Temperature", which can be
Hot. In this case, the relationship Cool < Mild < Hot is semantically meaningful, so you can probably get away with ordinal encoding if you want.
However, you still have to ensure that the ordinal relationship is preserved in your encoding, and scikit-learn's
LabelEncoder does not take care of this for you. To illustrate, look at how "Temperature" is being encoded:
Hot => 1
Mild => 2
Cool => 0
That's no good! You want
Hot to have the highest value. Instead you should use scikit's
OrdinalEncoder and explicitly tell it how to order the categories:
from sklearn.preprocessing import LabelEncoder, OrdinalEncoder
outlook_encoder = OrdinalEncoder(categories=['Rainy', 'Overcast', 'Sunny'])
X['Outlook'] = outlook_encoder.fit_transform(X['Outlook'])
temp_encoder = OrdinalEncoder(categories=['Cool', 'Mild', 'Hot'])
X['Temp'] = temp_encoder.fit_transform(X['Temp'])
# humidity and wind are binary features, so we don't need the ordinal encoder
humidity_encoder = LabelEncoder()
X['Humidity'] = humidity_encoder.fit_transform(X['Humidity'])
windy_encoder = LabelEncoder()
X['Windy'] = windy_encoder.fit_transform(X['Windy'])
Although there do exist ordinal relationships in most of your categorical features, you should still feel free to use one-hot encoding. It's always a safe bet when you're dealing with categorical features.
Since your dataset is small, you should experiment with both and see which gives the best results!