CSI 4144: Competitive Learning, Fall 2018
This course is a topics course in problem solving and algorithms. It is modeled on the collaborative and competitive environments at the ACM International Collegiate Programming Contest. Each week we will discuss a topic, and the assignments will be programming-based problems related to that topic.
Lectures are Tuesdays from 15:30 to 16:20 in Cashion C201.
My office location and office hours are listed on my home page. I am glad to talk to students during and outside of office hours. If you can't come to my office hour, please make an appointment for another time, or just stop by.
The schedule of assignments will be on Kattis.
Textbooks & resourcesThe textbook for this course is Competitive Programming by Steven Halim and Felix Halim (Edition 1 is free online, editions 2 and 3 are inexpensive).
The following books may also be useful:
- Programming Challenges by Steven Skiena
- The Algorithm Design Manual by Steven Skiena
- Introduction to Algorithms by Cormen et al.
- Programming Pearls by Jon Bentley
- Any other data structures, algorithms, and language reference books.
Other online programming contest software:
- Open Kattis -- this is the software used to judge the ACM ICPC contest world finals
Other online resources:
- Bruce Eckel, Thinking in C++ (2nd edition)
- the Standard Template Library (STL) reference
- Project submission guidelines and coding style guidelines for this course.
Grades will be assigned based on the following breakdown:
- First semester students:
- # of problems completed: 100%
- Second and third semester students:
- # of problems completed: 80%
- problem(s) developed: 20%
Final letter grades will be assigned at the discretion of the instructor, but
here is a minimum guideline for letter grades:
A: 90-100, B+: 88-89, B: 80-87, C+: 78-79, C: 70-77, D: 60-69, F: 0-59
Each problem completed within 1 week of it being assigned earns 2 points. Each problem not completed within a week but completed by the end of the problem session earns 1 point. Completing a program means passing the (hidden) tests on the judge.
For weeks designated as "exams" or "contests", we will work together to find an in-class examination time that works for everyone.
Students taking the course for the second (third) semester must develop one (two) problems of their own. Use the Kattis problem package and fill in the relevant parts. In particular, your writeup should have:
- A Latex writeup.
- At least one correct, efficient, well-structured, well-commented, one-file solution in C++ or Java.
- Possibly other submissions that highlight incorrect solutions (wrong answer, too much time, etc.)
- Files containing sample and secret inputs (each having suffix ".in"). The size of all inputs combined should be less than 500 Kb.
- Files containing sample and secret outputs (each having suffix ".ans"). The size of all inputs combined should be less than 500 Kb.
- An input format validator. It should use exit code 42 when the input file is correctly formatted, another exit code when there is a problem.
- A test case generator which generates input file (may be written in C++, Java, Perl, or Python). This should probably have some hand-made test cases hard coded in, as well as some randomly created test cases.
- An appropriately filled-in problem.yaml file.
The reason we use Kattis problem package format is due to the set of tools that are available for verifying problem integrity. You can use them in one of three ways:
- Install them
from github on the Kattis
problemtools project page. (They are easiest to install on Ubuntu.) As the
problemtools package uses a Git submodule, to get the full source you need to
use the following command to get all the sources you'll need:
git clone --recursive firstname.lastname@example.org:Kattis/problemtools.git
- Put your program on csi4144.ecs.baylor.edu, which is a linux server which has problemtools already installed, and run problemtools software there.
- Download a docker image -- use the latest-tagged version, something like:
docker pull hamerly/kattisproblemtools:v1.20180426This docker image is based on Ubuntu 18.04 and has problemtools already installed.
You can use this software to verify your problem package before submitting it to me. This means running "verifyproblem" to verify the entire problem package. You can also use "problem2pdf" to see how your problem writeup looks when rendered in PDF.
There are multiple deadlines for problem writeups, which are listed on the schedule above:
- The first deadline is a 1-2 paragraph description of the problem idea(s), including the motivation, type of problem (search, shortest path, dynamic programming, etc.), and the basic story outline for the problem.
- The second deadline ("Complete draft") means all parts of the problem package(s) should be written -- solution, writeup, input verifier, problem data, etc. The package should verify with Kattis problemtools "verifyproblem". I will evaluate these and send feedback for the final version.
- The deliverable of the final deadline is the same as that of the complete draft, except it should be highly polished and in final form. Even with a complete draft that is in good shape, getting a well-crafted problem can be a lot of work, so don't put off working on this.
- This website contains the official course information. Please check it regularly for updates.
- All work in this course is strictly individual, unless the instructor explicitly states otherwise. While discussion of course material is encouraged, collaboration on assignments is not allowed. Collaboration includes (but is not limited to) discussing with anyone (other than the professor) anything that is specific to completing an assignment. You are encouraged to discuss the course material with the professor, preferably in office hours, and also by email.
- Bring any grading correction requests to your professor's attention within 2 weeks of receiving the grade or before the end of the semester, whichever comes first.
I take academic honesty very seriously. Many studies, including one by Sheilah Maramark and Mindi Barth Maline have suggested that "some students cheat because of ignorance, uncertainty, or confusion regarding what behaviors constitute dishonesty" (Maramark and Maline, Issues in Education: Academic Dishonesty Among College Students, U.S. Department of Education, Office of Research, August 1993, page 5). In an effort to reduce misunderstandings, here is a minimal list of activities that will be considered cheating in this class:
- Using a source other than the optional course textbooks, the course website, or your professor to obtain credit for any assignment.
- Copying another student's work. Simply looking over someone else's source code is copying.
- Providing your work for another student to copy.
- Collaboration on any assignment, unless the work is explicitly given as collaborative work. Any discussion of an assignment or project is considered collaboration.
- Studying tests or using assignments from previous semesters.
- Providing someone with tests or assignments from previous semesters.
- Turning in someone else's work as your own work.
- Giving test questions to students in another class.
- Reviewing previous copies of the instructor's tests without permission from the instructor.
Title IX Office
Baylor University does not discriminate on the basis of sex or gender in any of its education or employment programs and activities, and it does not tolerate discrimination or harassment on the basis of sex or gender. This policy prohibits sexual and gender-based harassment, sexual assault, sexual exploitation, stalking, intimate partner violence, and retaliation (collectively referred to as prohibited conduct). For more information on how to report, or to learn more about our policy and process, please visit www.baylor.edu/titleix. You may also contact the Title IX office directly by phone, (254) 710-8454, or email, TitleIX_Coordinator@baylor.edu.