Tracks

Ordered paths through the problem catalogue - how the counts work, what Continue picks, and what happens to a problem that is withdrawn after you start.

View as .md

A track is an ordered path through the catalogue: a named goal, sections in order, and problems in order inside each section. /tracks lists them.

They exist because a long list of problems has no opinion about what you should do next, and for most people that is the actual obstacle - not the difficulty of any individual problem.

Reading a track#

Each section shows its own n/m - "Arrays 6/8". That count is the entire difference between a path and a list. A forty-problem track is a wall; a section you can finish tonight is not.

The whole track carries a count too, and a difficulty band telling you roughly who it is for.

Continue#

If you are signed in and part-way through, the track offers Continue. It opens the first required, unsolved problem in reading order - so it always agrees with the first unticked row you can see further down the page.

Three states, and they are genuinely different:

  • Signed out - no Continue. The page is fully readable; you are not walled out of it.
  • Part-way - Continue, pointing at the next one.
  • Finished - it says so rather than pointing anywhere.

Two things that affect the count#

Optional problems#

Some items are marked optional - stretch problems that belong on the path but are not required to finish it. They do not count in either half. Without that, somebody who has done everything the section asked would stare at "7/8" forever.

Withdrawn problems#

Occasionally a problem is retired after a track was assembled. When that happens the row stays on screen, struck through and not clickable, and it is removed from both halves of the count.

Both parts matter. Dropping the row would silently shorten your path with no explanation. Leaving it in the count would ask you for something you can no longer open.

Progress is worked out fresh every time#

Nothing stores "you are 12/40 through this track". It is derived from what you have actually solved, each time the page loads.

That is why a curator adding a problem to a section is immediately reflected for everybody, rather than leaving a stale counter that is wrong for every member and tells none of them.

Was this page helpful?

Last checked against the product on . Behaviour changes are listed in the changelog.