Merge branch 'master' of https://github.com/thecodingwizard/usaco-guide

content/1_Intro/Modules.mdx

@@ -5,48 +5,50 @@ author: Nathan Wang, Benjamin Qi
 description: How this guide is organized.
 ---
 
-All material in this guide will be grouped into **modules** such as the one you're reading right now.
+The material in this guide will be grouped into **modules** such as the one you're reading right now. A module will consist of several resources, practice problems, and additional content specific to the module. 
 
-## Lesson
-
-  - Goal is to introduce you to the concept.
+## Lesson <!--- what's this? is a lesson equivalent to a module? --->
+  - The goal is to introduce you to the concept.
   - Everything is meant to be completed in order.
-  - Usually begins with at least one standard problem.
-  - External resources (text, possibly videos) will generally be placed in tables like the one above. We'll **star** those that we expect you to read.
+  - Usually begins with at least one standard problem, marked "Intro" in the difficulty column.
+  <!--- Go through and mark standard problems (relative to topic) Intro? --->
+  - External resources will be placed in tables like the one above. We'll **star** those that we highly recommend you read.
 
 <spoiler title="Hidden Content">
 
-If we expect you to spend time thinking about a sample problem before checking the solution we'll place the solution in **spoiler blocks** like this.
+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-content title="Optional Content">
 
-It's okay to skip over these. Some material in these boxes might not be useful for competitive programming.
+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-content>
 
 ## Implementations
 
-Code should compile by itself, example input / output should be provided. Macros should generally be avoided.
+All implementations should compile, have example input / output provided, and have relatively few macros. If any code does not compile or is hard to read, submit a complaint using the "Contact Us" tab.
 
   - For Bronze, we will provide code snippets in C++, Java, and Python.
-  - For Silver and Gold, we will provide code snippets in C++ and Java and (sometimes) Python.
+  - For Silver and Gold, we will provide code snippets in C++ and Java and sometimes Python.
   - For Platinum, code snippets might only be provided in C++.
 
 <warning-block>
 
-Will contain common errors that you should avoid.
+A warning block like this will contain common errors that you should avoid.
 
 </warning-block>
 
-(code style guide?)
+<!-- Code Style Guide? Though I think forcing a style onto people is kind of bad, maybe just avoid things that are generally bad... -->
 
 ## Practice
 
 <info-block title="Pro Tip">
 
-Maybe helpful bits of advice.
+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-block>
 
@@ -54,9 +56,13 @@ Maybe helpful bits of advice.
   - Problems should be sorted in order of how they are recommended be completed.
     - Add comments regarding solution sketches.
   - At some point we'll write full editorials for those problems which don't have them (or if existing editorials are poorly written).
-  - Difficulty ranges from "Very Easy" to "Insane." Difficulty is **not** comparable across modules (even of the same division).
+  - Difficulty ranges from "Very Easy" to "Insane." Difficulty is **not** comparable across modules (even of the same division), but rather relative to the topic <!-- (in other words, if a problem can easily be solved using some topic, then it will be marked "Easy" or "Intro" even if very few people solved it in contest because they didn't know the topic). (Uncomment if nobody has problems with this interpretation) -->
     - "Intro" refers to a problem that just asks you to implement a standard algorithm or data structure.
-
+    - "Easy" refers to a problem that can be solved relatively quickly be someone who is familiar with the module, while also approachable by someone who has just finished reading the starred resources.
+    - "Medium" refers to a problem which requires a bit more thinking, but can also be solved by people who have done sufficent <!-- relative to person --> practice of easy problems.
+    - "Hard" refers to a problem which may take a lot of time to approach. However, if someone has done a large number of "Medium" problems and has a strong understanding of a topic, could theoretically be solved during a USACO contest. <!-- 4 / 5 hour period? depends on problem really. and person (if you're Benq you'll solve it in the contest period) -->
+    - "Very Hard" refers to a problem that will challenge even very strong contestants and often requires multiple levels of observations and more knowledge than provided by the module. <!-- (Uncomment?) You will probably end up reading editorials for most of these problems, but try to solve at least one by yourself. -->
+    - "Insane" refers to problems that are often horribly misplaced in their division. These problems are often a bad representation of the difficulty of problems in a USACO division. However, this does not mean that these problems cannot be interesting. If you want a challenge, try them out.
 
 <!-- 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:
 
@@ -64,4 +70,6 @@ Maybe helpful bits of advice.
   - 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. -->
+Old gold problems should probably be bumped up one level. -->
+
+<!-- Re: above. Almost-solved is subjective to problem though. Incorrect greedy "almost solves" deleg.""

content/3_Bronze/Ad_Hoc.mdx

@@ -11,10 +11,12 @@ import { Problem } from "../models";
 export const metadata = {
   problems: {
     general: [
-      new Problem("Bronze", "Mad Scientist", "1012", "Normal", false, [], "Flip all ranges that mismatch greedily."),
       new Problem("Bronze", "Cow Tipping", "689", "Hard", false, [], "Cells in the last row and column can be toggled uniquely. Toggle the appropriate ones and then recurse to the rectangle in the previous row/column, and solve the same way."),
       new Problem("Bronze", "Race", "989", "Very Hard", false, [], "Greedily increment/decrement Bessies speed to fit the conditions until her total distance exceeds K."),
     ],
+    greedy-tutorial: [
+      new Problem("Bronze", "Mad Scientist", "1012", "Normal", false, [], ""),
+    ]
   }
 };
 
@@ -32,8 +34,35 @@ Since Ad Hoc problems don't fall under any specific category, they can be hard t
 
 These tips are very useful in solving Ad Hoc problems. However, in the end, the best way to get better at Ad Hoc problems (or any type of problems) is to do a lot of them. Try to solve as many practice problems below as you can, and click the solution sketch tab if you can't figure the solution out.
 
+## Greedy Problems
+
+One thing to note about Ad Hoc problems in the USACO Bronze division is that many of them, while difficult to categorize into specific algorithms or data structures, can be solved using **Greedy** techniques. While this idea will be covered more in future [modules](https://usaco-guide.netlify.app/silver/greedy), we'll introduce the general mindset in this section.
+
+When approaching a greedy problem, we want to make argument about the structure of the solution of the problem. Specifically, that certain "greedy" actions, or actions that create the best possible solution at some local point in the algorithm, will lead to an optimal solution at the end. 
+
+Consider some possible greedy algorithms for the USACO Bronze problem "Mad Scientist."
+
+<problem-list problems={metadata.problems.greedy-tutorial} />
+
+<spoiler title="Correct Greedy Algorithm">
+
+ In this problem, the correct greedy solution is to continually flip the longest possible ranges of mismatching cows. 
+
+ Mad Scientist has an excellent [editorial](http://www.usaco.org/current/data/sol_breedflip_bronze_feb20.html) with a video solution and intuitive proof. It is highly recommended you read it before continuing to gain a better understanding of the greedy algorithm.
+</spoiler> 
+
+However, not all greedy problems in the bronze division nessecarily require mathematical proofs of correctness. It is often good enough to intuitively convince yourself your algorithm is correct.
+
+<info-block title="Pro Tip">
+Sometimes, if the algorithm is easy enough to implement, you don't even need to convince yourself it's correct: just let the online judge prove it for you by coding it and seeing if it passes. This is often called a Proof by AC.
+
+<!-- Don't overuse it though? -->
+
+</info-block>
+
 <problems-list problems={metadata.problems.general} />
 
 <IncompleteSection>
 
-</IncompleteSection>
+</IncompleteSection>
+<!-- Anything else major that needs to be added? Bronze Ad Hoc is not very complicated. -->