Python代写|FIT2004 S2/2022: Assignment 2



Learning Outcomes

This assignment achieves the Learning Outcomes of:

  • 1) Analyse general problem solving strategies and algorithmic paradigms, and apply them to solving new problems;
  • 2) Prove correctness of programs, analyse their space and time complexities;
  • 3) Compare and contrast various abstract data types and use them appropriately;
  • 4) Develop and implement algorithms to solve computational problems.

In addition, you will develop the following employability skills:

  • Text comprehension.
  • Designing test cases.
  • Ability to follow specififications precisely.

Assignment timeline

In order to be successful in this assessment, the following steps are provided as a suggestion.

This is an approach which will be useful to you both in future units, and in industry.


  1. Read the assignment specifification as soon as possible and write out a list of questions you have about it.
  1. Clarify these questions. You can go to a consultation, talk to your tutor, discuss the tasks with friends or ask in the forums.
  1. As soon as possible, start thinking about the problems in the assignment.
  • It is strongly recommended that you do not write code until you have a solid feeling for how the problem works and how you will solve it.
  1. Writing down small examples and solving them by hand is an excellent tool for coming to a better understanding of the problem.
  • As you are doing this, you will also get a feel for the kinds of edge cases your code will have to deal with.
  1. Write down a high-level description of the algorithm you will use.
  2. Determine the complexity of your algorithm idea, ensuring it meets the requirements.


  1. Think of test cases that you can use to check if your algorithm works.
  • Use the edge cases you found during the previous phase to inspire your test cases.
  • It is also a good idea to generate large random test cases.
  • Sharing test cases is allowed, as it is not helping solve the assignment.
  1. Code up your algorithm (remember decomposition and comments), and test it on the tests you have thought of.
  1. Try to break your code. Think of what kinds of inputs you could be presented with which your code might not be able to handle.
  • Large inputs
  • Small inputs
  • Inputs with strange properties
  • What if everything is the same?
  • What if everything is difffferent?
  • etc…

Before submission

  • Make sure that the input/output format of your code matches the specifification.
  • Make sure your fifilenames match the specifification.
  • Make sure your functions are named correctly and take the correct inputs.
  • Make sure you zip your fifiles correctly (if required).


For this assignment (and all assignments in this unit) you are required to document and comment your code appropriately. Part of the marks of each question are for documentation. This documentation/commenting must consist of (but is not limited to):

  • For each function, high-level description of that function. This should be a two or three sentence explanation of what this function does and the approach undertaken within the function.
  • For each function, specify what the input to the function is, and what output the function produces or returns (if appropriate).
  • For each function, the appropriate Big-O or Big-Θ time and space complexity of that function, in terms of the input size. Make sure you specify what the variables involved in your complexity refer to. Remember that the complexity of a function includes the complexity of any function calls it makes.
  • Within functions, comments where appropriate. Generally speaking, you would comment complicated lines of code (which you should try to minimise) or a large block of code which performs a clear and distinct task (often blocks like this are good candidates to be their own functions!).

A suggested function documentation layout would be as follows:

def my_function(argv1, argv2):


High level description about the functiona and the approach you

have undertaken.




:Output, return or postcondition:

:Time complexity:

:Aux space complexity:


# Write your codes here.

1 Gotta Go Fast

(10 marks, including 2 marks for documentation)

Caffffeine runs through your veins and you can’t function without it. No matter where you go,you would need to grab a cup of coffffee1 on the way to the destination. You, however, often fifind yourself late to your destination due to this; especially when the cafes have a long waiting time.

Thus, you vow to never be late again – for a computer scientist is never late nor early, one arrives precisely when one means to… cause one is effiffifficient using Graph algorithms of course!

With that, you have downloaded the travel time between key locations in your city which you can use to estimate the travel time from a point to another. You have also time the waiting time of each cafe that you would grab your coffffee from.

Given your FIT2004 study, you have come to the realisation that it is possible to model your travels using the RoadGraph data structure:

  • The RoadGraph class implementation is as described in Section 1.1. An example of the graph structure is provided below.
  • You can then calculate the optimal routes for your commute while grabbing coffffee along the way using a function in the RoadGraph class called routing(self, start, end) detailed in Section 1.2.

class RoadGraph:

def __init__(self, roads, cafes):

# ToDo: Initialize the graph data structure here

def routing(self, start, end):

# ToDo: Performs the operation needed to find the optimal route.

1.1 Graph Data Structure (3 mark)

You must write a class RoadGraph that represents the road network in the city.

The __init__ method of RoadGraph would take as an input a list of roads roads represented as a list of tuples (u, v, w) where:

  • u is the starting location ID for a road, represented as a non-negative integer.
  • v is the ending location ID for a road, represented as a non-negative integer.
  • w is the time taken to travel from location u to location v, represented as a non-negative integer.
  • You cannot assume that the list of tuples are in any specifific order.
  • You cannot assume that the roads are 2-way roads.
  • You can assume that the location IDs are continuous from 0 to |V | − 1 where |V | is the total number of locations.
  • The number of roads |E| can be signifificantly less than |V |2 , therefore you should not assume that |E| = Θ(|V |2).

The __init__ method of RoadGraph also takes as an input a list of cafes cafes represented as a list of tuples (location, waiting_time) where:

  • location is the location of the cafe; represented as a non-negative integer.
  • waiting_time is the waiting time for a coffffee in the cafe, represented as a non-negative integer.
  • You cannot assume that the list of tuples are in any specifific order.
  • You can assume that all of the location values are from the set {0, 1, . . . , |V|-1}.
  • You can assume that all of the location values are unique.
  • You cannot assume waiting_time to be within any range except that it is a value > 0.