Downloads · 30 days
0
Liori25/bike-sharing-random-forest
bike-sharing-random-forest is a machine learning model from Liori25. Use it for the machine learning task on the model card, and read the license before you ship it in a product.
Lior Feinstin Assigment. <video controls width="640" <source src="https://huggingface.co/Liori25/bike-sharing-random-forest/resolve/main/Task2.mp4" type="video/mp4" </video
Downloads · 30 days
0
Access
Public
Updated Dec 9, 2025
Repo size
497 MB
Likes
0
Public
Click a slice to open those files.
.pkl459 MB · 91%
From the Hugging Face model README
Lior Feinstin Assigment. <video controls width="640"> <source src="https://huggingface.co/Liori25/bike-sharing-random-forest/resolve/main/Task2.mp4" type="video/mp4"> </video>
I selected Bike Sharing in Washington D.C. Dataset , I am using only the "hour.csv" file for my analysis. The hourly dataset contains about 17,000 records, where each row represents one hour and includes:
Target variable
cnt – total number of bike rentals (casual + registered) in that hourTime-related features
yr – year (0 = 2011, 1 = 2012)mnth – month (1–12)hr – hour of the day (0–23)weekday – day of the weekseason – season (1: spring, 2: summer, 3: fall, 4: winter)holiday – whether the day is a holidayworkingday – whether the day is a working day (not weekend/holiday)Weather-related features
temp – normalized temperatureatemp – normalized “feels like” temperaturehum – normalized humiditywindspeed – normalized wind speedweathersit – weather situation category (clear, mist, light snow/rain, heavy rain/snow)Regression:
Given the time and weather conditions, how many bikes will be rented in that hour?
Classification:
Based on the same features, will demand in that hour be low, medium, or high?
season contained only values 1–4 (no invalid codes such as 5 or 6).Because the data was already clean and well-structured, no rows had to be dropped or imputed.
it is possible but not likly that the humidy on this instant was zero. therefore, I won't be delting this data.

Outliers were found, especially in the rental counts during certain hours/Casual Riders/Registered Riders. However, after examining these data points, they appeared to be genuine high-demand hours, such as:
These observations are not data errors but real behavioral patterns. Therefore, they were kept in the dataset rather than removed.
To better understand relationships between variables, a correlation heatmap was created (see attached figure in the full report).

temp and atemp have the strongest positive correlation (~0.99), confirming that perceived temperature closely follows actual temperature.cnt (total rentals) shows strong positive correlations with:
registered (~0.97) – most rentals come from registered users.casual (~0.69) – casual users also drive demand.temp and atemp (~0.40) – warmer conditions are associated with higher usage.casual correlates positively with temp (~0.46) and atemp (~0.45), suggesting that casual riders are more weather-sensitive.hum) has a moderate negative correlation with cnt (~–0.32), indicating that high humidity tends to reduce bike usage.To understand the distribution of key variables, several histograms were plotted.

Temperature (temp)
The distribution of temperature is approximately bell-shaped, indicating that most hours occur around moderate temperatures, with fewer hours at extreme cold or heat.
Rental count (cnt)
The distribution of cnt is right-skewed:
This suggests that while most hours have moderate or low demand, there are distinct peak periods with very high usage.


Bike rentals decrease steadily as weather conditions worsen:
This suggests that unfavorable weather strongly suppresses demand.

Insights:
This indicates that commuting patterns are one of the main drivers of hourly bike demand.

The average number of total rentals is slightly higher on working days than on weekends and holidays, but the difference is not dramatic:
Overall, bike demand remains relatively steady throughout the week, with commuting patterns boosting working-day usage and leisure activities balancing demand on non-working days.
Insights:
Casual riders show a sharp decline in usage as weather worsens:
Registered riders also reduce their usage in poor weather, but the decline is more gradual:
These patterns show that weather has a stronger impact on casual, leisure-based usage than on registered, commuting-based usage.
The goal of the baseline model is to predict the number of bikes rented per hour (cnt) using weather conditions, time-related features, and day-type information.
I selected features that have a clear relationship with bike demand, based on exploratory data analysis (EDA):
temp, hum, windspeed, weathersithr, weekday, mnth, season, yrholiday, workingdayThis feature set is designed to capture environmental, temporal, and behavioral factors that influence hourly rental counts.
The data was split into training and test sets (80/20). Several columns were excluded before modeling:
cnt – target variable (to be predicted, not used as input)dteday – date string; not directly useful for the baseline modelinstant – record index; acts like an ID and carries no predictive informationcasual, registered – their sum is cnt, so using them would leak the answeratemp – almost perfectly correlated with temp (~0.99), so it was dropped to avoid redundancyThe dataset includes features on different scales (e.g., hr ranges 0–23, while temp, hum, windspeed are normalized between 0 and 1). To prevent features with larger numeric ranges from dominating the Linear Regression model, I applied StandardScaler to the numeric variables. This puts all features on a comparable scale and makes the baseline model more stable and interpretable.
A Linear Regression model was trained on the selected, scaled features.
Model performance was evaluated on the test set using:


(Actual vs. Predicted plot – image to be added here.)
This plot compares predicted rental counts to the true values. Points lying far from the diagonal line indicate prediction errors and show that the baseline linear model struggles with some high-demand hours.

A residual is defined as:
residual = actual value − predicted value
The residual plot shows “unbehaved” residuals, with large positive and negative values and no clear random pattern. This suggests that the baseline Linear Regression model does not fully capture the complexity of the relationships in the data (non-linearity, interactions, etc.).

Using the absolute values of the Linear Regression coefficients, the most influential features in the baseline model are:
temp) – strongest positive coefficient; higher temperatures are strongly associated with more rentals.hr) – important predictor, confirming strong time-of-day patterns in demand.yr) – positive coefficient, indicating that overall usage increased from 2011 to 2012.hum) – large negative coefficient; higher humidity tends to reduce rentals.season) – positive contribution, suggesting higher demand in certain seasons (e.g., summer and fall).Other features such as holiday, weekday, and windspeed have relatively small coefficients, indicating a weaker direct effect in this simple linear baseline model. These findings motivated further feature engineering and the use of more flexible models in later parts of the project.
I created polynomial features for the main weather variables:
temp2 = temp²hum2 = hum²windspeed2 = windspeed²Logic:
The effect of weather on bike rentals is not purely linear. Very low and very high temperatures tend to reduce demand, while moderate temperatures increase it. Squared terms allow the model to capture these curved (U-shaped or inverted U-shaped) relationships between weather conditions and rental counts.
I transformed the hour of the day (hr) and the month (mnth) into cyclical features using sine and cosine:
hr_sin, hr_cosmnth_sin, mnth_cosLogic:
Time-of-day and seasonality are cyclical: after hour 23 comes hour 0, and after December comes January. A simple numeric encoding (0–23, 1–12) makes the model treat “23” and “0” as far apart, which is not true in time. Cyclical encoding preserves the circular structure and helps the model understand that “late night” and “early morning” are close to each other.
I added several binary flags to capture different usage regimes, for example:
Logic:
Bike usage patterns differ between commuting times and leisure times. Morning and evening peaks on working days usually reflect commuting behavior, while weekend evenings are more related to leisure rides. These flags help the model distinguish these patterns instead of treating every hour in the same way.
I defined indicators such as:
is_mild_temp – comfortable temperature rangeis_too_cold / is_too_hot – extreme temperaturesis_bad_weather – rainy/snowy or otherwise unpleasant conditionsLogic:
Users are more likely to rent bikes when the weather is comfortable and less likely during very cold, very hot, or rainy/snowy conditions. Instead of expecting the model to infer all thresholds from raw numbers, explicit comfort and bad-weather flags make these patterns easier to learn.
I added interaction terms, for example:
yr_season – interaction between year and seasonLogic:
The effect of one variable often depends on another. For example, the morning peak matters mainly on working days, and bad weather may have a stronger impact during typical commuting times. Interaction features allow the model to capture these “it depends on…” relationships and changes in demand patterns across the year.
For the categorical variables:
seasonmnthhrweekdayweathersitI used One-Hot Encoding within a ColumnTransformer. Each category value (for example, season = summer) is converted into its own binary column that takes the value 0 or 1.
Logic:
Linear and tree-based models do not work well with raw integer codes for categories, because they may incorrectly assume an order or distance (e.g., “season 4” > “season 1”). One-Hot Encoding represents categories in a way that does not impose any artificial ordering.
To capture typical usage regimes (combinations of time, calendar, and weather), I applied K-Means clustering on a subset of features.
Time / calendar:
weekday, workingday, season, yrWeather:
temp, hum, windspeed, weathersitEngineered features:
hr_sin, hr_cosis_morning_peak, is_evening_peakis_weekend, is_weekend_eveningis_mild_temp, is_too_cold, is_too_hotis_bad_weatherNote: The raw hr column was removed from the clustering features, and only hr_sin and hr_cos were used to represent the circular nature of the hour.
I plotted:

By combining both plots, I chose k = 8, which:
I used PCA to reduce the clustering feature space to two principal components, and plotted the observations in this 2D space, colored by their K-Means cluster ID.

Insight:
The PCA plot looks relatively messy because it compresses many features into just two linear components, so clusters that are well separated in higher dimensions can overlap in 2D. To better show local structure and separation between clusters, I also used t-SNE.

In the t-SNE map, the clusters form several compact “islands” of points with relatively clear boundaries between many of the colors. This suggests that the K-Means algorithm has found groups of hours that are locally well separated in terms of time, calendar, and weather characteristics.

I created a cluster interpretation table (average features and average cnt per cluster) to understand the characteristics of each of the 8 clusters.
Cluster 3 – Cold, low-demand off-peak hours (~47 bikes)
temp ≈ 0.19, is_too_cold = 1.00), mostly clear weather.Cluster 0 – Bad-weather hours with suppressed demand (~111 bikes)
weathersit = 3, is_bad_weather = 1.00 → rain/snow conditions.Cluster 1 – Working-day off-peak with mild conditions (~118 bikes)
workingday = 1.00), no peak flags.temp ≈ 0.50, hum ≈ 0.65).Cluster 6 – Weekend daytime with mild weather (~173 bikes)
is_weekend = 1.00, workingday = 0.00).is_mild_temp = 0.44).Cluster 5 – Weekend evenings, warm weather (~221 bikes)
is_weekend = 1.00, is_weekend_evening = 1.00).temp ≈ 0.51, is_too_hot = 0.15).Cluster 2 – Hot mid-day hours with high demand (~257 bikes)
temp ≈ 0.80, is_too_hot = 1.00) with mostly good weather.Cluster 4 – Working-day morning commute (~352 bikes)
workingday = 1.00, is_weekend = 0.00).is_morning_peak = 1.00, mostly mild temperatures.Cluster 7 – Working-day evening commute, warm (~450 bikes)
is_evening_peak = 1.00.temp ≈ 0.58, is_too_hot = 0.25).cnt → weekday evening commute with very high rentals.Yes, the clusters are useful and align well with real-world patterns:
cnt varies strongly across clusters (from ~47 to ~450 rentals), which means that cluster ID is strongly related to demand.For these reasons, the cluster assignments (and distances to cluster centroids) were used as additional features in the regression and classification models to help capture complex, non-linear demand regimes.
For the improved regression task, I trained and compared three models on the engineered + cluster features:
All models used the same feature set and the same train–test split.
Features (X):
Engineered features + clustering features (time, calendar, weather, cyclic encodings, flags, and cluster ID).
Target (y):
cnt – total number of bike rentals per hour.
Preprocessing:
season, mnth, hr, weekday, weathersit).StandardScaler.Pipelines:
For each model, I built a scikit-learn Pipeline containing:
preprocessing → regressor (Linear Regression, Random Forest, or Gradient Boosting).
Evaluation:
A helper function was used to fit each model and compute metrics on train and test sets.




Random Forest achieves the lowest RMSE and MAE among all models, which means it makes the smallest prediction errors on hourly bike rentals on the test set. It also has the highest R², indicating that it explains the largest proportion of the variance in bike demand compared to the other models (i.e., its predictions follow the true rental patterns most closely).
Overfitting occurs when a model fits the training data too closely (very low training error) but performs worse on new data, while underfitting happens when a model is too simple and has relatively high errors on both train and test sets.
Linear Regression with engineered features
Shows similar but moderate errors on train and test, which indicates underfitting: the model cannot fully capture the complexity of the data.
Random Forest Regressor
Fits the training data very strongly and shows a small increase in error on the test set, which reflects some overfitting.
However, Random Forest still has by far the lowest test RMSE and MAE and the highest R² of all models, so it is selected as the best model despite this mild overfitting.

num__hr (the hour of the day after numeric preprocessing), confirming the strong time-of-day pattern in demand.temp has the largest positive coefficient, making it the most important feature in the linear model.These results highlight the importance of both time-of-day and temperature in explaining bike rentals.
Baseline vs. engineered Linear Regression
The baseline Linear Regression on original features achieved test RMSE ≈ 139.4, MAE ≈ 105.0, and R² ≈ 0.39.
After adding engineered features (cyclical time, peak-hour flags, comfort/bad-weather indicators, clusters), Linear Regression improved to RMSE ≈ 92.9, MAE ≈ 69.5, and R² ≈ 0.73, showing that the new features capture important structure in the data.
Tree-based models on engineered data
These results indicate that non-linear tree models can exploit the engineered features more effectively than Linear Regression.
Reason for overall improvement
The main factor behind the improvement over the baseline model is the feature engineering step. By adding richer features (cyclical hour encoding, peak-hour and weekend indicators, comfort vs. extreme weather flags, and cluster-based features), the models receive a much more informative description of each hour and can better learn how time, day type, and weather jointly affect demand. Linear Regression already benefits significantly from these engineered features, and the tree-based models (Random Forest and Gradient Boosting) can exploit them even further by modeling non-linear relationships and interactions that the baseline linear model could not capture.
Random Forest Regressor is the best model for this dataset because:
For these reasons, Random Forest was selected as the final winning regression model.
The plots clearly show that the Random Forest with engineered features fits the data much better than the baseline Linear Regression without feature engineering.
I reframed the regression problem as a three-class classification task by discretizing the hourly rental counts into:
using the 33% and 66% quantiles of cnt computed on the training set.
Why this strategy?
Quantile-based binning produces roughly equal-sized classes, which helps the classifier learn effectively and avoids severe class imbalance.
The resulting classes are indeed well balanced: each class contains about one third of the observations in both the training and test sets.

Precision vs. Recall (for this task)
For the bike-rental task, recall for the high-demand class is more important than precision.
Missing a true high-demand hour (low recall) means stations may not have enough bikes, leading to lost revenue and unhappy users. Over-predicting high demand (lower precision) is less harmful, because having a few extra bikes available is usually acceptable. Therefore, recall (and F1) for the high-demand class is a key evaluation metric.
False Positives vs. False Negatives
A False Negative (predicting “not high” when demand is actually high) is more critical, because it directly harms service reliability: stations can run out of bikes, frustrating users and damaging trust.
A False Positive (predicting high demand when demand is normal) mainly causes over-allocation of bikes, which has some operational cost but does not usually hurt the customer experience. Thus, reducing False Negatives is the priority.
I trained three different classification models on the engineered + cluster features:
For each model, I computed the classification report (precision, recall, F1-score, support) and plotted a confusion matrix.

Logistic Regression
Classifies most hours correctly but struggles with the medium-demand class: medium hours are often predicted as low or high, while direct confusions between low and high are rare. Most errors are off by one level (medium ↔ low/high).
RandomForestClassifier
Shows a very strong diagonal in the confusion matrix: the vast majority of low, medium, and high-demand hours are correctly classified. Remaining errors are mainly between neighboring classes, with almost no low↔high confusions.
GradientBoostingClassifier
Also predicts most hours correctly; errors occur mainly between adjacent classes (low vs. medium, medium vs. high), and direct low↔high mistakes are very rare.
Based on the test-set metrics (accuracy, macro precision, macro recall, macro F1), the RandomForestClassifier is the best of the three classifiers:

Technically, RandomForestClassifier performs best because it is an ensemble of many decision trees, which can model complex non-linear relationships and interactions between time variables and weather conditions that a single linear model cannot represent.
The winning classification model (RandomForestClassifier pipeline) is available here:
https://huggingface.co/Liori25/bike-sharing-random-forest/tree/main
thank you