Machine Learning in Engineering Science / Fall 2026 / Homework

Build and Explain a Stock Forecasting System

Can an LSTM forecast the next trading day's closing price better than a simple baseline, under an honest evaluation protocol?

Submission: individual project and a five-minute video in English. Due date and submission platform: to be announced by the instructor.

1. Learning objectives

• Convert a financial time series into correctly aligned input windows and prediction targets.
• Compare persistence, linear regression, and an LSTM using the same information and test dates.
• Prevent future information from leaking into preprocessing, model selection, and evaluation.
• Produce an experiment another student can reproduce and explain where the system fails.

2. The system you must build

Build one complete workflow: load a saved CSV, check the data, create chronological splits, construct windows, train the models, generate predictions, and display evaluation results. A clearly organized Colab or Jupyter notebook is a sufficient system. A separate web application, live trading connection, paid data feed, and cloud deployment are not required.

The prediction is issued after the market closes on trading day t. For a lookback of L observations, define:

Here P is your declared daily closing-price series. The horizon is the next trading observation, not necessarily the next calendar day. Begin with closing price as the only feature. Use L = 20 for the main model comparison; also compare L = 10 versus L = 20 for the LSTM on validation data.

3. Data and provenance

1. Choose one stock or market ETF and obtain at least 750 daily trading observations from a permitted historical-data source. Do not use fabricated data as the final experiment.
2. Save the exact CSV used in the experiment. Include at least date and close; record the ticker, market, currency, source URL, retrieval date, date range, and whether prices are adjusted or unadjusted.
3. Use one consistent price definition across all models. Explain stock splits, dividends, or vendor adjustments that could affect interpretation. A retrospectively adjusted download is not proof that identical data were available historically.
4. Sort dates in increasing order; check duplicates, missing values, and non-positive prices. Report your cleaning decisions. Do not invent weekend observations or interpolate prices using future values.
5. Record a SHA-256 checksum of the saved CSV. Respect the provider's license; if redistribution is restricted, provide a permitted instructor-access route and exact acquisition instructions rather than publishing the data publicly.

4. Chronological evaluation: non-negotiable rules

• Split the ordered observations into approximately 70% training, 15% validation, and 15% test. Print the exact boundaries and counts. Assign a window to a split using its target date.
• Fit scalers and any learned preprocessing using training observations only. Apply those fitted transformations to validation and test observations. Do not fit on the complete series.
• Every input must precede its target. Show one sample with all input dates and its target date to demonstrate the alignment.
• Validation and test windows may include earlier observations from the preceding split. For rolling one-step evaluation, already observed test prices may enter later test inputs; future test prices may not. Keep model weights fixed during the test period.
• Use validation results to choose the LSTM lookback and settings. Freeze these decisions before evaluating on the test set. Do not repeatedly tune using test scores, and do not randomly split overlapping windows.
• Compare all final models on exactly the same test target dates and in the original price units, not normalized units.

Explain that rolling one-step prediction with newly observed history is different from forecasting an entire future month recursively. This HW requires only the former.

5. Required models and experiment

Keep the work practical for a free Colab session or local CPU: for example, no more than 20 training epochs per configuration, batch size 32, and early stopping based on validation loss. Record the actual architecture, loss, optimizer, learning rate, epoch limit, stopping rule, and seed. Transformer and attention models are optional extensions, not prerequisites for full marks.

6. Results and interpretation

Provide the following evidence, generated from your actual run:

1. One split diagram: show the complete price history with training, validation, and test boundaries.
2. One validation comparison: compare the two LSTM lookbacks and justify your selected configuration without consulting test results.
3. One test-score table: MAE and RMSE for persistence, Ridge, and the selected LSTM, on identical dates. State which error is being averaged and the price units.
4. One aligned forecast plot: show actual and predicted test prices with correct target dates. Include a zoomed interval so a smooth-looking curve cannot conceal errors.
5. One learning-curve plot: show LSTM training and validation loss and explain evidence for underfitting or overfitting.
6. One failure analysis: examine the date with the largest absolute LSTM test error. Report the observed price, prediction, persistence prediction, and error. Discuss plausible limitations without inventing a causal market explanation.

Calculate MAE = mean(|prediction - target|) and RMSE = sqrt(mean((prediction - target)²)) after converting predictions back to the original units. Explain why tracking the price level closely does not, by itself, demonstrate reliable direction prediction or a profitable strategy.

Interpretability requirement: explain the information each model receives, what the LSTM is intended to retain over time, and what your evidence cannot establish. The lookback comparison is a controlled sensitivity experiment, not a causal explanation. If you add attention weights or feature-attribution plots, do not present them as proof of causality.

7. Five-minute video: required storyboard

Record a screen presentation with your own English narration. Target 5:00 minutes; an acceptable range is 4:30-5:30. Show your notebook and actual results, not only prepared slides. A webcam is optional.

Do not replace your explanation with AI-generated narration. AI may help you draft the script, but you must understand and explain the submitted work yourself. Supply an instructor-accessible video link or an MP4; check viewing permissions before submission.

8. Submission checklist

• stock_forecasting.ipynb: executed from a clean runtime, with visible outputs and detailed English Markdown explaining each step.
• README: exact run instructions, data acquisition/provenance, chosen settings, split dates, and limitations.
• Saved input CSV when redistribution is permitted; otherwise the permitted access route and acquisition instructions. Include its checksum and any cleaned-data snapshot needed to reproduce the run.
• requirements.txt or an environment/version report, a recorded seed such as 2026, and a configuration file or clearly labeled configuration cell. Report any nondeterminism; a seed alone does not guarantee bitwise-identical results.
• test_predictions.csv: target date, previous close, observed close, persistence prediction, Ridge prediction, and LSTM prediction. Include a metrics table and the required figures.
• ai_use_log: tool/model used, representative prompts, assistance received, and the changes or checks you performed. Write "No AI assistance" if none was used. Never include credentials or private account information.
• Your five-minute video and its access link, if applicable.

Package these in one folder or ZIP. No trading account, paid AI subscription, paid API key, custom domain, or public repository is required.

9. Grading rubric

A missing baseline, future-data leakage, or tuning on the test set makes the affected model comparison invalid. Document a failed run honestly rather than inventing results. Scores are based on submitted evidence, not unsupported claims.

10. Official technical references

• TensorFlow: Time series forecasting - windows, baselines, and sequence forecasting examples.
• scikit-learn: Common pitfalls and recommended practices - preprocessing consistency and data-leakage prevention.
• scikit-learn: TimeSeriesSplit - an optional reference for chronological cross-validation; a fixed chronological split is sufficient for this HW.