This repository has been archived on 2022-06-22. You can view files and clone it, but cannot push or open issues or pull requests.
usaco-guide/content/1_Intro/Modules.mdx
2020-07-17 18:29:45 -07:00

104 lines
5.3 KiB
Text

---
id: modules
title: Modules
author: Nathan Wang, Benjamin Qi
description: How each module is structured.
---
The material in this guide will be grouped into **modules** such as the one you're reading right now. A module generally consists of three parts:
1. **Lesson**: Introduces the concept.
2. **Implementations**: Code!
3. **Practice Problems**: Teaches you how to apply the concept to various problems.
<!-- 3. **Additional Content**: Optional resources related to the module, for those who are interested -->
## Lesson
The lesson is a curated collection of external resources, problems, and supplementary text we've written ourselves.
- The goal is to introduce you to the concept.
- Everything is meant to be completed in order.
- It usually begins with at least one **standard problem**, marked "Intro" in the difficulty column.
- The standard 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.
## Implementations
Usually the lesson is followed by an implementation of the solution to the standard problem.
- C++ code will always be provided.
- Java code will be provided (at least) for Bronze - 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 standard problem. Implementations we provide will follow certain [conventions](./code-con).
## 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.
### 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._
_Pre-release note_: Currently, very few problems have full editorials. We've provided some temporary _solution sketches_ (very short solution explanations) while we continue working on this guide. If you believe an editorial is needed for a problem, please let us know using the "Contact Us" button.
### Problem Difficulty (Bronze - 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.
<!-- ## Additional Content
Some modules may also have additional content at the end that isn't needed for USACO, but may be interesting. Feel free to read or skip them as you'd like. -->
## Interactive Elements
Sometimes modules will contain interactive elements. Here are some of the more common ones.
<Info title="Pro Tip">
Helpful bits of advice provided by the author.
<!-- Tips on how to become legend in CP and better at competitve programming by Benjamin Qi, exactly what you wanted when you spam DM'd him! Definitely take these tips seriously. Don't uncomment this. -->
</Info>
<Spoiler title="Hidden Content">
In some modules, codes or solutions will be placed in **spoiler blocks** like this. In these cases, you should think about the problem or try to implement it yourself before revealing the solution or code.
</Spoiler>
<Optional title="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.
</Optional>
<Warning>
A warning block like this will contain common errors that you should avoid.
</Warning>
<!-- Difficulty should be comparable across a division. Say that you have *almost-solved* a question if you scored at least $n-2$ out of $n$ test cases. At least for platinum, difficulty levels should correspond approximately to the following USA Pre-college almost-solve rates on a USACO contest:
- Easy: $\ge 40\%$ (ex. Fort Moo, Team Building, Redistricting)
- Normal: $\ge 20\%$ (ex. Card Game, Balancing, Gathering)
- Hard: $\ge 10\%$ (ex. Mooriokart, Train Tracking 2, Friendcross)
Old gold problems should probably be bumped up one level. -->
<!-- Re: above. Almost-solved is subjective to problem though. Incorrect greedy "almost solves" deleg."" -->