Submission deadlines
Your group must submit several things during the course. Here each submission is described in a bit more detail, in chronological order.
w3
Fri 19/1: Form groups and set up GitHub
Each group should have preferrably 4–5 students, and you don’t have to know each other beforehand. When you have created a group, set up Git and GitHub:
- The first you have to do is to create a GitHub account (if you don’t already have one).
- Then you have to set up git, and make Git and GitHub work together.
- There are apps that you can install so you don’t have to do the fetching, pulling, committing and pushing from the command line. Two free suggestions are GitHub’s own client (Mac/Windows), and SourceTree.
After this, your group should set up your own project repository of the Shrdlite project:
- Go to the invitation.
- One of you creates a new team and gives it the same name as your group is called (i.e., Bstar, Cstar, Xstar, or whatever your group is called).
- The rest of your group joins the new team.
- You will now get a new private repository which is a fork of the initial Shrdlite repository.
- Note that your repository is private, which means that you shouldn’t share your code with anyone else!
When your repository is set up, notify the course responsible with the following information:
- The name/URL of your project repository.
- The names, personnummer, study programme, email addresses and GitHub accounts of you and your group members.
- Your supervision restrictions: i.e., which times on Wednesdays/Thursdays you cannot have weekly supervision.
Now you can start coding. Make sure to update and commit your repository regularly! When we grade your code, we will look at the commit history of your repository. This is both a way for you to prove that everyone in the group has contributed, and as a safeguard against plagiarism.
w5
Wed 31/1–Thu 1/2: Submit Lab 1, A*
Submission: You submit the A* lab by presenting it at your weekly supervision meeting. Bring a computer and show that it works correctly – your supervisor will ask questions about your code to make sure that you understand what you have implemented.
Important: Everyone in the group must be prepared to answer the questions, so make sure that everyone understands how the code works!
Your group will implement the A* search algorithm, and you will then use this implementation in your Shrdlite project.
The Shrdlite project has a file called AStarSearch.ts, which has a dummy function
called aStarSearch. The body of this function should be replaced by
your actual implementation.
Before submitting, you must ensure that your implementation passes all the test problems.
These are available in the repository and can be invoked by compiling test-astar.ts,
and then invoking node test-astar.js N
(where N is the number of the test case you want to run, or all if you want to run all tests).
The data for the test problems are in the file AStarTestCases.ts.
All test problems are in a simple 2d grid labyrinth, the TypeScript definitions
of this labyrinth graph is in the file GridGraph.ts.
For each test case it calls your implementation and checks if the returned solution is an optimal solution. It does this with two admissible heuristics; one is the Manhattan heuristcs, and one is a trivial return-0-heuristic. Afterwards it compares number of visited nodes and the running times, with and without the Manhattan heuristic.
w6
Wed 7/2–Thu 8/2: Submit Lab 2, Interpreter
Submission: You submit the Interpreter lab by presenting it at your weekly supervision meeting, just as you did for the A* lab (see above).
Important: Everyone in the group must be prepared to answer the questions, so make sure that everyone understands how the code works!
The second part of the Shrdlite project is the interpreter. At this point in the project, you should be familiar with the Shrdlite pipeline (i.e. Parser -> Interpreter -> Planner), even if you haven’t started on the Planner yet. Simply put, the interpreter is tested by running the entire Shrdlite program with the last step (Planning) cut out.
Before submitting, you must ensure that your implementation passes all the test problems.
They are available in the file InterpreterTestCases.ts, and you test them by
compiling test-interpreter.ts and then invoking node test-interpreter.js N
(where N is the number of the test case you want to run, or all if you want to run all tests).
The program reports if you have interpretations that are incorrect, or if you have missed some
interpretations that you should have returned.
Note:
Please read the file InterpreterTestCases.ts carefully, and update it!
About 1/3 of the tests don’t have an interpretation yet, but you should decide what their interpretation should be.
Be prepared to answer questions about how you decided your interpretations.
w9
Tue 27/2: Submit Essay
You submit your essay in PDF format using the EasyChair conference system:
- [TBA]
Important: Everyone of you has to create an EasyChair account, and then one of you becomes the “corresponding author”. (Note that it has no effect whatsoever on your grades who is corresponding author).
After you create an account on EasyChair, please notify Claes and your supervisor details including the email address used to signup on EasyChair, your group number and name. Also include the topic you have chosen to write your essay on. Do not forget this as you will not be able to review essays without doing this.
Wed 28/2–Thu 1/3: Submit Lab 3, Planner + basic Shrdlite project
Submission: You submit the Planner lab by presenting it at your weekly supervision meeting, just as you did for the previous labs.
Important: Everyone in the group must be prepared to answer the questions, so make sure that everyone understands how the code works!
The third and final part of the Shrdlite project is the planner. Here you connect your A* implementation with the Shrdlite world and the interpretation result. When this is done you should have a functioning Shrdlite system.
Before submitting, you must ensure that your implementation works correctly, both in the “offline” (terminal-based) version, and in the “online” (browser-based) version.
Wed 28/2–Thu 1/3: Submit suggestions for extensions
If you want to get a higher grade on the project than a 3 / G (Chalmers / GU, respectively), you can implement extensions to Shrdlite. More on this on the Shrdlite page. You must discuss all of these with your supervisor before implementing them!
This week’s supervision meeting is when you tell which extensions you plan to implement.
Important: If you don’t tell your supervisor about an extension, then we will not take that into account when grading your final project! I.e., this week is the deadline for deciding about the functionality of your system.
w10
Tue 6/3: Submit Essay Review
After the submission deadline, every student will be assigned one essay each written by your fellow students which they should read and review. You submit your review via EasyChair too, using your personal EasyChair account. After the review process, each group will be able to see the reviews that they got for their own essays.
Note: This task is individual! You are allowed to discuss your assigned essays with each other, and how to write the review, but you should write it yourself.
w11
Tue 13/3: Submit final Shrdlite project
Submission: You submit the final project by committing it to your repository. That’s it. We will discuss your code during the oral exam next week.
The Shrdlite implementation must be working and in good shape before the final submission! In general, your implementation must be documented, logical, readable and have no dead code. If an extension does not work, you must remove it from the submitted code.
Important: Don’t modify the repository after Tuesday 13th March!
We will take snapshots of all student repositories, so there’s no use trying to change the commit history. But you’re all honest guys, so you wouldn’t even think of that, would you?
Wed 14/3–Fre 16/3: Oral project examination
The oral examination works similar to the supervision sessions, but there will be two teachers present. The exam is 30 minutes and starts with you showing your project, describing the functionality, and giving a short explanation of how the extensions work. This should take c:a 10 minutes. Then we will ask you detailed questions about the project.
Important: Everyone in the group must be prepared to answer the questions, so make sure that everyone understands how the code works!
Fri 16/3: Submit final Essay
You have to revise you essay according to the reviews you received. Note that you do not have to follow every advice that the reviewers gave, only those that make sense to you and that you believe will make your essay better. Your final essay should be uploaded to EasyChair before the deadline.
The final essay should not be anonymised, so add your names below the title.
Important: Together with your final essay, you have to write a short text describing which of the reviewers’ issues you have addressed (and in which way) and what you have decided not to care about. Add this description as an extra page at the end of your essay (as an appendix, after the references).
Fri 16/3: Submit individual evaluation
Every group member must fill in an individual self- and peer-evaluation. Submit this via email to the course responsible.
The evaluation form can be downloaded from here (in Microsoft Word format).
This assessment is an important part of the examination for the project and the essay. It consists of answering a bunch of questions about your own involvement and your group members. This shouldn’t take more than an 15–30 minutes.
Note: This task is individual! You should not cooperate within the group when writing your answers. We teachers will check that your answers are consistent within the group. In rare cases, we might ask you for additional information, e.g., if two group members have completely different views of how the work was done.
w12
Fri 23/3: Resubmit Shrdlite project (if necessary)
If your project needs a resubmission, then you have to do the following:
- Commit the whole project to GitHub.
- Email the course responsible a zip file with the functioning project.
- Add a README file detailing how you have addressed the problems you faced in the submission, and detailing your individual contributions.
- Be available for clarification questions from the teachers-