Setting up your machine

Python, the supplied lab codebases, and what preparing for a lab means

Two things are assumed on arrival: Python, and one introductory course in probability and statistics. No knowledge of Formula 1 is assumed and none is rewarded — where a domain fact is needed, the page needing it explains it in the sentence that uses it.

The machine#

Python, a way of making a project environment, and a way of installing packages into it. That is the whole toolchain; nothing in it is course-specific.

Week 1’s session is a drop-in for getting that working on the machine you intend to use for the rest of the semester, while somebody who can fix it is standing there. Its page lists what week 2 expects to be working, and those lines hold whether or not you come.

What a lab codebase is#

Every Lab arrives as its own codebase with a part of it left out, and no Lab imports another. The shape does not change: make an environment for that week’s codebase, install its dependencies into it, and run the test suite it came with until it passes. The suite tells you the install is finished rather than how the Lab is marked; a suite that fails on your machine while passing on ours is one of the things week 1’s session is for.

What “prepared beforehand” means#

A Lab is prepared before the session and completed inside it, so the preparation is the part that happens on your own time: the codebase installed with its tests passing, and whatever that week’s brief asks you to arrive having read. Each Lab’s own page carries its preparation, and the labs page carries how they are marked.

The workload this is built against is 2 hours of lecture, 2 hours of Lab and around 6 hours of independent work a week. Lab preparation sits inside those independent hours rather than beside them.

Described rather than linked, and there is nothing to download: this is a prototype of the course site, and neither the instructions nor the codebases are part of it.