Define the prediction before choosing the model.
“Forecast bike demand” is incomplete. A valid problem specifies what is predicted, when the prediction is made, how far ahead it reaches, and what information exists at that moment.
Availability question
At 8 p.m. Sunday, we forecast Monday's total rentals. May we use Monday's observed temperature? Monday's weather forecast? Sunday's rentals?
The forecasting contract
For the first conceptual pass, aggregate the Kaggle hourly rows into daily totals. This reduces visual clutter while preserving time order, weekly seasonality and future-information constraints. We return to hourly forecasting when engineering features.
Target
Daily total rentals aggregated from hourly count.
Forecast origin \(t\)
Sunday at 8 p.m.
Horizon \(h\)
One day ahead.
Frequency
One observation per calendar day.
Inputs
History through Sunday and forecasts known by Sunday.
Decision
How many bikes to prepare across the system.
Read the notation: \(\widehat y_{t+h\mid t}\) is the estimate for time \(t+h\), made using the information set \(\mathcal I_t\) available at origin \(t\).
Split question
Why is a random 80/20 split invalid when rows are days?
Time order changes the learning problem
Ordinary supervised learning often assumes rows are exchangeable. A time series usually violates that assumption: nearby observations share state, regimes change, and information has a timestamp.
Three distinctions to settle early
Univariate
Predict demand using its own history.
With predictors
Add calendar, weather, price, or events—but only when available.
One versus many steps
Tomorrow's forecast and the next 14 days are different tasks with different uncertainty.
Exogenous does not mean known. A weather variable comes from outside the demand series, but its future realized value is still unknown. Use a weather forecast, scenarios, or a model that does not require it.