The project is worth 5% of your grade. Here is a breakdown of the pieces of the project, as portions of your final grade:
The 3% that comes from grading rescues is determined by ranking everyone for how they did on all inputs, then grading based on each group's average rank. A leaderboard will be kept using Gradescope for the evaluation rescues, which will tell you your approximate position among the class.
We think that everyone in the class should be able to get 3% without too much work - putting some effort in the project will show in your design doc and final presentation, and you will be able to pick up an additional 1% on evaluation.
|Monday 4/22||Evaluation rescues||Design doc|
|Monday 5/6||Evaluation rescues, Final presentation|
Please sign up your group by 4/15 using this google form. You must submit this form, even if you are working alone. We assign group tokens using this form, and if you do not submit this form by 4/15 you will not be able to be evaluated.
Please write and submit to Gradescope 1 page answering the following questions:
- If there was a Guavabot on every node, what sequence of scouts and remotes would you do to get them all home?
- More generally, if you knew where all the bots were, what sequence of scouts and remotes would you do to get them all home?
- If you didn't care about getting the bots home and just wanted to find their locations as quickly as possible, what sequence of scouts and remotes would you do?
- What ideas do you have for solvers? Please provide at least 2. What are their advantages/disadvantages?
- What kinds of inputs do you think your solvers will do well on? Do poorly on?
There are no right answers. This is different than a homework problem: we are not grading this on correctness, just on effort and answers that show some understanding of the problem. This is your time to think of interesting ideas and write them down, you can test them with the test inputs later.
You don't have to write LaTeX if you don't want to. Any neatly typed report PDF is fine. The names of all group members should be on the PDF.
For grading, we will give you 1% if the design doc looks good and 0% if we think it needs some work. We will send you an email if you are given a 0%, and if you meet with us you can get the 1 if you don't want to. Any neatly typed report PDF is fine
3% of your grade will come from a set of evaluation outputs. (These are common to the entire class.) We will drop the lowest 12% of your evaluation scores. If you complete any evaluation rescue by 4/29 at 11:59pm, we will drop an additional 1% of your evaluation scores. In this case, "complete" means submitting a token with your score(s) on the Gradescope leaderboard assignment.
WARNING: YOU CAN ONLY BE EVALUATED ON EVERY OUTPUT ONCE. We will not create additional outputs for fairness for the class, so you should run the evaluation outputs once you are confident in your solver. Again, for fairness we cannot give you more outputs.
The skeleton will warn you when you are running on evaluation rescues, and it only lets you run some number at a time. We highly recommend you start evaluation early, and evaluate at a good pace leading up to the deadline.
When you run on some evaluation inputs, the API gives you a submission token describing how you did. Submitting that token to Gradescope updates the leaderboard, showing you how well you are doing compared to other students in the course. YOU ARE ONLY GRADED ONCE YOU SUBMIT THE TOKEN TO GRADESCOPE, YOU WILL NOT RECEIVE ANY POINTS FOR EVALUATION RESCUES CONDUCTED AFTER THE DEADLINE.
Evaluation rescues will all be released on 4/22, and all evaluation rescues will be due on Monday 5/6.
During the Friday of the last week of lecture and Monday and Tuesday of RRR week, we will hold final presentations. These are for us to get a sense of how the project went for you, what approaches you tried, what worked and didn't work. We will release signup slots when the time comes. Your entire group must be present, otherwise you will not receive full credit.
We will also open up an assignment on Gradescope for you to submit an outline for your presentation that we will use for reference. When the time comes, we will release questions you should answer in your outline and final presentation. You need to submit an outline to get credit for your presentation, but the point of the outline is for us to reference during the final presentation.
Collaboration and External Resources¶
Here are some rules and guidelines to keep in mind while doing the project:
- You can collaborate freely within your group.
- No sharing of any outputs, in any form
- No sharing of code, in any form. This includes making public forks of the skeleton on Github and modifying them. Please keep your repositories private.
- Informing others about available libraries is encouraged in the spirit of the project. You are encouraged to do this openly, on Piazza.
- Informing others about available research papers that are potentially relevant is encouraged in the spirit of the project. You are encouraged to do this openly, on Piazza.
- Informing others about possible reductions is fine, but treat it like a home-work question - you are not to give any substantial guidance on how to actually think about formulating the reduction to anyone not in your team.
- As a general rule of thumb: don’t discuss things in such detail that after the discussion, the other teams write code that produces effectively the same outputs as you. This should be a general guideline about how deep your discussions should be.
- If in doubt, ask us. Ignorance is not an excuse for over-collaborating.
You may only use free services (academic licenses included). This includes things like free AWS credits for students. If you use AWS or any other cloud computing service, you must cite exactly how many hours you used it for in your project report. We should be able to replicate the results that you cite. If you use any non-standard libraries, you need to explicitly cite which you used, and explain why you chose to use those libraries. If you choose to use the instructional machines, you may only use one at a time PER TEAM. Anybody who uses multiple instructional machines will receive a zero for the evaluation part of the project.
As a final note, as staff, we generally trust that students will make the right decisions when it comes to academic honesty, and can distinguish collaboration from cheating. However, we’d like to point out that what has made this project so interesting in the past is the wide diversity of student approaches we observe to a single problem. We could have elected to give you yet another problem set, but we believe that the open ended nature of this project is a valuable experience for students to have. Do not deprive yourselves or us of this by over-collaborating or simply taking the same approaches you find your peers using.