PrevNext

Introducing Modules

Authors: Nathan Wang, Benjamin Qi

How each module is structured.

There are six sections in the guide: Intro, Bronze, Silver, Gold, Platinum, and Advanced. Each section is subdivided into categories, which is just a group of modules. Each module (such as the one you're reading right now) represents one "article" or "page" on the site. A module generally consists of three parts:

  1. Lesson: Introduces the concept via a focus problem.
  2. Implementations: Solutions to the focus problem.
  3. Practice Problems: Teach you how to apply the concept to various problems.

Some relatively rare modules are prefixed with "optional." It's not essential to work through these if your goal is just to pass the corresponding division. They might be referenced in later divisions.

Lesson

The lesson is a curated collection of external resources, problems, and supplementary text we've written ourselves.

  • We'll link to online resources that already exist whenever possible.
  • The goal is to introduce you to the concept.
  • Everything is meant to be completed in order.
  • It usually begins with at least one focus problem.
    • The focus problem is a direct application of the concept, and is useful in testing your implementation.
  • We'll star external resources that we highly recommend you read. Feel free to read the others if you don't understand something. If multiple modules cover essentially the same material, at most one should be starred.

Implementations

Usually the lesson is followed by an implementation of the solution to the focus problem.

  • C++ code will always be provided.
  • Java code will be provided (at least) for Bronze to Gold.
  • Python code will be provided (at least) for Bronze and some of Silver.

Example input / output will be provided if not already contained within the statement of the focus problem.

Practice Problems

After reading the module lesson, you'll be given a lot of problems (from various sources, not just USACO) to practice applying the concept you've learned.

  • The problems are roughly sorted in order of how they are recommended to be completed.
  • You don't have to solve every problem, just enough to feel comfortable with the module. We've starred the ones we found most interesting.

Please let us know if the problem is not a good example of the corresponding topic!

Problem Editorials

We'll try our best to write full editorials for problems which don't have them (or if existing editorials are poorly written). Starred problems will generally have better editorials. If you believe an editorial is needed for a problem, please let us know using the "Contact Us" button.

Warning!

A lot of current sketches are not actually useful.

Problem Difficulty (Bronze to Gold)

Difficulty represents how challenging a problem is expected to be to someone after they read through the module, not how difficult the problem is in general. Therefore, it is not comparable across modules (even of the same division).

Difficulty ranges from Very Easy to Insane.

  • Very Easy problems are related to the module, but you should be able to do them relatively quickly before reading the resources.
  • Easy problems can be solved relatively quickly by someone who is familiar with the module, and they should be approachable by someone who has just finished reading the starred resources.
  • Normal problems require a bit more thinking.
  • Hard problems may require a lot (?) of time to approach.
  • Very Hard problems challenge even the strongest contestants in the corresponding division. Often require multiple levels of observation and more knowledge than provided by the module.
  • Insane problems shouldn't appear on a (reasonable) contest of the corresponding division. Don't worry about solving these until you've reached a higher division.

Conventions for Sources and Tags

  • Follow the format of existing sources and tags from the problems page.
  • Split separate tags into separate strings (e.g., ['Meet in the Middle', 'DP'] rather than ['Meet in the Middle, DP']).
  • Some sources are automatically assigned tooltips that display when hovered over. For a source not automatically assigned a tooltip, you can give it one by specifying sourceDescription.

Custom Components

Sometimes modules will contain custom components. Here are some of the more common ones.

Pro Tip

Helpful bits of advice provided by the author.

Hidden Content

Optional: Optional Content

Not all content in this guide is essential to competitive programming. Skipping over optional content is fine, but if you're interested, feel free to explore further as well.

Warning!

Pay attention to content within warning blocks!

See Working With MDX for more information regarding custom components.

Statuses

Problem Statuses:

  • Not Attempted - Self-explanatory.
  • Solving - Self-explanatory. Will show up under dashboard active problems.
  • Solved - Self-explanatory.
  • Reviewing - Use for problems that you have solved and want to show up under dashboard active problems.
  • Skipped - Use for problems that you have skipped and intend to come back to. Will show up under dashboard active problems.
  • Ignored - Use for problems that you have skipped and do not intend to come back to. Will show up under dashboard active problems if enabled in settings.

Module (and Resource) Statuses:

  • Not Started - Self-explanatory.
  • Reading - Self-explanatory. Will show up under dashboard active modules.
  • Practicing - Self-explanatory. Will show up under dashboard active modules.
  • Complete - Self-explanatory.
  • Skipped - Use for modules that you have skipped and intend to come back to. Will show up under dashboard active modules.
  • Ignored - Use for modules that you have skipped and do not intend to come back to. Will show up under dashboard active modules if enabled in settings.

Module Progress:

Join the USACO Forum!

Stuck on a problem, or don't understand a module? Join the USACO Forum and get help from other competitive programmers!

PrevNext