Submission deadlines

Your group must submit several things during the course. Here each submission is described in a bit more detail, in chronological order.

w12

Fri 24/3: Form groups and set up GitHub

Each group should have 4–5 students, and you don’t have to know each other beforehand. When you have created a group, set up Git and GitHub:

After this, your group should set up your own project repository of the Shrdlite project:

When your repository is set up, notify the course responsible with the following information:

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.

w13

Wed 29/3–Thu 30/3: Submit group contract

Submission: Your group should formulate and sign a contract between yourselves, and submit to your supervisor at your first supervision meeting.

This contract governs how you will collaborate during the course. It should state how you will behave towards each other, and how you resolve conflicts or standstills in the group. Here are some specific questions that you should try to answer in the contract:

w14

Wed 5/4–Thu 6/4: 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 Graph.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 TestAStar.ts, and then invoking node TestAStar.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.

w16

Wed 19/4–Thu 20/4: Resubmit Lab 1, A* (if necessary)

Submission: You resubmit the A* lab by presenting it at your weekly supervision meeting, just as you did for the original submission (see above).

Important: Everyone in the group must be prepared to answer the questions, so make sure that everyone understands how the code works!

w17

Wed 26/4–Thu 27/4: 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 TestInterpreter.ts and then invoking node TestInterpreter.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.

w18

Wed 3/5–Thu 4/5: Resubmit Lab 2, Interpreter (if necessary)

Submission: You resubmit the Interpreter lab by presenting it at your weekly supervision meeting, just as you did for the original submission (see above).

Important: Everyone in the group must be prepared to answer the questions, so make sure that everyone understands how the code works!

w19

Fri 12/5: Submit Essay

You submit your essay in PDF format using the EasyChair conference system:

First, one of you has to create an EasyChair account, and then that person 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 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.

w20

Wed 17/5–Thu 18/5: Submit suggestions for Shrdlite extensions

If you want to get a higher grade 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. Your supervisor can ask questions about what ideas

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.

Fri 19/5: Submit Review

After the submission deadline, you will be assigned 2 essays written by your fellow students which you should read and review. You submit your review via EasyChair too. After the review process, each group will be able to see the reviews that they got for their own essays.

w21

Fri 26/5: Submit 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 Friday 26th May!

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?

w22

Mon 29/5–Wed 31/5: Oral project examination

Every group should book a time slot for the oral exam, here: http://doodle.com/poll/372rtzik9bbcawig

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 and the essay.

Important: Everyone in the group must be prepared to answer the questions, so make sure that everyone understands how the code works!

Fri 2/6: 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.

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 2/6: 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.

w23

Fri 9/6: Resubmit Shrdlite project (if necessary)

If your project needs a resubmission, then you have to do the following:

  1. Commit the whole project to GitHub
  2. Email the course responsible a zip file with the functioning project
  3. Add a README file detailing how you have addressed the problems you faced in the submission
  4. Be available for clarification questions from the teachers