Computer Science Large Practical (2013—2014)

Course Description

The Computer Science Large Practical exposes students to the problems that arise with the design and implementation of large scale computer systems, and to methods of coping with such problems. Students will gain experience in how to:

Further details can be obtained by visiting the drps page for the course.




There is no exam for this course, assessment is 100% based on the assigned coursework.


The coursework will be detailed further in the lectures.

The coursework handout is available here.

Example coursework input will appear in the Coursework Examples tab above.

General University and School of Informatics rules for course work


There are two parts, the deadlines are:



The coursework handout is available here.

The slides for the first lecture are available here.

There was a typo in the coursework handout which has now been fixed. It confused the words “alights” and “disembarks” as well as “leaves” and “departs”. The typo is fixed but to avoid confusion I will regard these as allowable synonyms. Hence you can regard “disembarks” and “alights” as synonyms for each other. Additionally you can regard “departs” and “leaves” as synonyms for each other.


Can I submit both an early submission version and a version for the end deadline and have the marks for whichever is highest?
No. Before the early submission deadline you have to choose whether or not you are going to hope for a mark above 90% now, or have an extra week to accumulate more marks up to 90%. The submission marked will be the latest one made before the deadline. Hence if you submit both before and after the early submission deadline, only the last submission will be marked and it will be capped to 90%.

There was a typo in the coursework handout which has now been fixed. It confused the words “alights” and “disembarks” as well as “leaves” and “departs”. The typo is fixed but to avoid confusion I will regard these as allowable synonyms. Hence you can regard “disembarks” and “alights” as synonyms for each other. Additionally you can regard “departs” and “leaves” as synonyms for each other.

In the first lecture I suggested that extension requests should go to the year organiser or the ITO. Having spoken with the year organiser he confirmed that all extension requests should go directly to the ITO who will then forward them on to the year organiser.

In the feedback to part one you suggested there was an error in my simulation which would produce incorrect results and that I should run this example through my simulator several times to see what the error is. I have done this but still cannot find the error in my simulator.

Several students had this problem. In part this is due to the way in which the algorithm is specified in the requirements. Whilst not wrong it is imprecise and as a result, many students have made a similar error.

Although imprecise, as requirements specifications go, this is about as detailed as you are ever likely to get. Worse still, some customers will believe that they know what the solution should be. This is especially true if you remain in academia and, for example, collaborate with other scientists. This practical is intended to provide a similar experience. Though of course it is necessarily more contrived than in reality.

In general, I hope that something you can learn here is that you will almost never have the task of blindly implementing a set of detailed requirements (which are common for coursework). You should see yourself as more creative. You are implementing a solution to a perceived problem. So you must ask yourself: is that bigger picture problem solved by my current implementation? Rather than: does my implementation meet all of the specified requirements?

Again, coursework is a rather contrived situation, so we necessarily must provide some well-defined requirements. In particular so that you know when to stop.

As to the solution to the particular problem exhibited by many students' submissions to part one, I offer some hints:

  • The fix should mean the modification of a few lines of code at most
  • The events that you will produce because of this bug are incorrect they are not impossible. All of the events that you produce are individually possible (assuming you have no other bugs).
  • It is really the timing of the events which are implausible given the input. In particular look at the time between two different events
  • I should be able to fix your code in order to allow the evaluation of everything else, without significant problem
Should I have one event for new passengers and upon firing that event randomly choose both an origin and destination stop, or should I have one new passenger event per stop.
The former.
Are the rates of the roads expected to be symmetric, so that I need only give a rate for a road between stop 1 and 2, but not additionally between stops 2 and 1.
No, they are not expected to be symmeteric and the road between stops 1 and 2 is different from any road between stops 2 and 1. Note that it won't often be the case that buses will go between two stops in different directions, since stops on opposite sides of the road are different stops. It is not impossible and does happen here in Edinburgh (see the west end of the 31 route for an example), but it is not the norm.
Should passengers be allowed to board a bus if there are passengers on that bus who want to get off it?

I'll accept either. The important thing is that you think about it. Even better if you document your decision. What do you think is reasonable? Have you tried simply implementing both? I personally think they can happen concurrently, but like I say, I'll accept either.

I think it won't make much difference in which order these events occur, although it should change the overall rate if you allow/disallow boarding and disembarking to proceed concurrently.

More generally, you have to be aware that the customer (who might be yourself, or a group of people including yourself, or it might be that you are not in the set of customers) will find it very difficult to describe what they want. You have to be prepared to think about what you are delivering, and not simply blindly follow a set of requirements. Even if the customer can write down what they want, it might be that there is a better solution than they have thought of. It might be that implementing their idea of a solution gives you a better idea.

I know that asking multiple times for clarification kind of defeats the purpose of having a similar to a real-life development project experience. On the other hand, when developing, developers are allowed to ask their clients about certain things and thus our correspondence ( if we presume you are the simulator's client) is somewhat realistic since you are also not allowed to give me straight solutions.
I'm not sure it does defeat the purpose. Customers are different, some like to be very involved in the project others prefer you to get on with it. For example if you were to stay in academia and collaborate with other scientists (who may be also computer scientists, or something else, such as physicists or biologists), then they are likely quite "hands-on" and would be happy to answer any and all questions and meet with you frequently. The unrealistic part is that I can probably give you an answer which is near-guaranteed to be correct. Whereas a customer does not always know what the best solution is, or even what they want.
Now, my problem is with the Average Bus Queuing Time part. The average queueing at all stops time should include ‘all occasions in which a bus has not had to queue at a stop at all’ and also should not include time spent by buses on the heads of queues. Does this mean that this statistics should include times buses spent while on queues (but not on their heads) AND on roads (since that's the only other place they can be)? This doesn't seem reasonable since we are calculating queueing times and times spent on roads are not really queueing times to me. Should I include the interpretation as an option (as I did with the passengers disembarking before boarding) ?
no it certainly does not include any time spent on the road between stops. The idea is to compute how long a bus can expect to be queued at a given stop. So every time a bus visits the stop (whether any passengers disembark/board or not), it will spend some time in the queue. Of course if there are no other buses there, then that time is zero. The point is that the 'zero' time should be included in the calculation of the average. So if a bus visits a stop twice, in the first case it is queued for 1 minute, and in the second case there are no other buses there when it arrives, then on average it has queued at that stop for 1/2 a minute.
I am unsure about what the behaviour in a particular situation should be. Should I include the two (or more) possible interpretations as an option?
Yes, that's an excellent solution. I would also of course document it. You do not need to worry about it for this practical, but more generally one does have to worry about providing too much choice to the user. But if the implementation is simple, you might provide a temporary option such that the customer can try both and then say which should be the deployed behaviour, with no associated option to change it.
Am I right to assume that we will only be dealing with 1 route at a time in an input file?
No there could well be multiple routes within an input file. The input describes a network, with possibly many routes and roads.
I am supposed to test my simulator on both valid and invalid input, does this mean valid input format or with respect to warnings/errors?
This really means with respect to warnings and errors. I won't be harshly testing your simulator on incorrectly formatted input. I will run your simulator on incorrectly formatted input as well. This is mostly just to see that you fail safely. Of course, a nice error message stating where in the input there is a syntax error would be a nice bonus, but it is not essential.
Is the route with only one stop valid or not?
Good question. This is a decision for you to make. Certainly I would document whatever decision you make. To be clear, either decision is not incorrect. It is justifiable either way. Personally I think I would make it invalid, since it is difficult to imagine this corresponding to any real world scenario. Arguably though, a modeller could be using such a singleton route to, for example, increase the likelihood of queuing at a particular stop. In this sense the modeller may be abstracting an entire portion of the network with a single circular route and bus. However, I personally think they could equally well do this with a two stop route.
I have a stupid question ...
I won't use a cliche and claim that there are no stupid questions, there are. However, if you're emailing me then I'm the only one who will know you asked it.
The input file may contain comments, they start with a # tag and end with a new line. However, can these comments appear everywhere in the file or just as a separate line?

It won't terribly matter either way. I won't stress test your parsing of comments, so something that simply checks even if the line begins with a # symbol is fine. It is more to allow yourselves to comment on your own test files.

That said, feel free to be more liberal and allow comments anywhere. It isn't so common now, but it used to be very common for sites requiring credit card numbers to refuse input which had spaces. I always wondered why. For me it would be less effort to strip the input of any spaces than it would to display a notice saying “no spaces allowed” (and check that that looks fine on a variety of resolutions etc.).

If 1 passenger misses 2 buses on the same stop do I count him/her as 1 missed passenger or as 2 because they have missed more than 1 bus?
Good question, this should be counted as 2 missed passengers. You are really counting occurrences of passengers missing buses, rather than the number of passengers themselves. Of course feel free to additionally count how many times passengers see more than one full bus go by them.

Slides and Lecture Log

Slides for upcoming lectures should appear here before the lecture and will remain once the lecture has been given. Slides are subject to some minor modifications at any time prior to the start of the lecture.

Introduction - 20th September

Slides are available here. I finished at the definitions slide here.

I gave an overview of the course and set out the main requirements for the main practical. I cautioned that these slides and this lecture should not be seen as a substitute for reading and comprehending the coursework handout.

Source Code Control - 27th September

Slides are available here. I actually started the lecture where I stopped for the previous one here. Finished to the end of the lecture on source code control.

Languages - 4th October

Slides are available here. I got through to the start of the discussion of lazy vs eager programming languages. I ended here.

Structure & Strategy - 11th October

I finished the lecture on Languages beginning where I left off last time. I then started the topic of Structure and Strategy lecture slides available here. I got to here where I'll pick up next time.

Structure & Strategy - 18th October

I completed the topic of Structure & Strategy, starting where I left off the last time, here.

Assessment & General Tips - 25th October

I gave some advice about the assessment and some more general tips. Slides start from here.

Part One Review - 1st November

I gave some general feedback on the submissions for part one. Slides start from here.

Example Input for the Main Coursework

Example input will be gathered here. More complex examples will appear throughout the first semester.


A very simple example: simple.text which should allow you to test an early version of your parser.

Several students had a similar bug in their part-one versions. I have suggested that simulating this example would hopefully highlight the source of their error.

Last Updated: 9th December 2013 --- Allan Clark

Home : Teaching : Courses 

Informatics Forum, 10 Crichton Street, Edinburgh, EH8 9AB, Scotland, UK
Tel: +44 131 651 5661, Fax: +44 131 651 1426, E-mail:
Please contact our webadmin with any comments or corrections. Logging and Cookies
Unless explicitly stated otherwise, all material is copyright © The University of Edinburgh