program代写、Python程序设计代写

日期：2023-05-04 08:43

Welcome to A2 - Mountain Climber!

Now that you've acquainted yourself with Stacks, Queues, Lists and the like, it's time to explore more complex data structures, and use them to solve more complicated tasks!

Rather than spending 4 weeks in tranquility, painting to our heart's content, we'll be getting some exercise and climbing some mountains for the next 5 weeks! In particular, we'd like to do some analysis and modelling of the mountain climbing we do, which you'll be helping us out with.

In this assignment, you'll work on the following features:

•A Mountain Trail representation

•A plot view that shows the longest trails suitable for a given hiker

•A trip organiser that keeps track of the relative ranking of trips

In doing this, you'll need to demonstrate knowledge on the following topics:

•Linked Structures

•Hash Tables and their various methods / approaches

•Use of recursive sorting algorithms and recursive methods

Please Note: With the advent of A2 the ban on python inbuilts is mostly lifted with the exception of the sorted function and dict inbuilt type! Feel free to use list and all other python functionality to its full extent.

The only exception on this exception is that if you are essentially using a list as a stack then please use the provided LinkedStack instead.

Please make sure to read the next slide for some important information before diving into the rest of the assignment.

Please read all instructions carefully. It is useful to have a general understanding of the app and of trails before you begin; however, you do not need a deep understanding to complete most of the tasks.

To reiterate what is said in the next slide, you do not need to read through or change the contents of main.py, draw_trails.py, or utils.py. Each task will specify what files need to be edited.

The template git repository can be found here. Follow the instructions in the "Getting Started with Git" document to copy across the repository (KEEPING IT PRIVATE) and get coding.

Important Information, Tips and Tricks

Before you get working on the application, please read these tips & tricks to ensure you don't get lost, or lose any silly marks!

Group Work

This is the first assignment you'll be doing in groups. Remember to sign & submit the group contract[LINK] and fill out the weekly check-ups!

Common Mistakes

You are marked on correctness in Ed. It doesn't matter if your code passes locally, it needs to pass in Ed. Contact a TA if you are having trouble achieving parity.

Be careful of the specific Python version used, and don't import any other third party modules excluding those already in requirements.txt.

Write clear and concise docstrings for methods you introduce / edit, and type-hint all methods / variables.

If introducing new classes, consider using dataclasses to simplify this definition.

Separate your code into small methods of at most 20 lines, and try to abstract logic if you find lots of duplicated work.

Note: Almost all methods in the sample solution are 10 lines or less. (Please ignore the mess that is draw_trails.py or main.py :} )

Initial Setup + Running Tests

To get up and running you want to do a few things:

Import the template repository - Follow the instructions in the Getting Started with Git page.

[Optional] Make a virtual environment for the project (Follow the instructions in the README file)

Install the required packages: python3 -m pip install -r requirements.txt

Test it is working by running python3 main.py  (This will raise NotImplemented errors if you haven't started on the assignment)

To run tests, call python run_tests.py. Note that you can restrict which tests are run using a second argument. For example, running python run_tests.py 1 will only run tests from the tests/test_trail/trail_TODO folder.

What files should I be editing?

Everything for the assignment can be solved in the following files:

mountain_manager.py

mountain_organiser.py

mountain.py

personality.py

trail.py

In particular, you do not need to read the following files:

main.py

serialize.py

draw_trails.py

utils.py

Assumptions & Tidbits

dataclasses are used in some of the scaffold code. In short, they do a lot of the initialisation boilerplate for you by inspecting the type hinting for class variables. You can read more about it here.

This project also uses abstraction with the abc module. You can read more about it here.

What is the app?

NOTE

The adding/removing mountains / branches feature won't work until you have implement the first task slide "Trail creation & Edit methods"

The graph feature won't work until you have implemented nearly everything (More Trail Methods, Mountain Manager, Mountain Organiser, Double Key Table)

This app gives information about a certain mountain range, which has various interconnected mountains.

Each mountain has three associated pieces of information:

The name of the mountain (text)

The difficulty level of climbing this mountain (integer)

The length across the mountain (integer)

This can be visualised nicely by main.py:

Each mountain is represented by the person walking up a hill icon, and the interconnected lines represent connections between mountains.

Here the red numbers on the left of each mountain represent the difficulty level, and the blue numbers on the right of each mountain represent the length.

As part of this assignment we'll be asking many queries about this collection of mountains.

On the right sidebar of the screen you'll see a few different buttons:

From top left to bottom right:

The plot icon shows a plot of mountains ranked by length as more difficulty levels are added. This is yet to be implemented, and is covered by Mountain Organiser and Manager.

The file icon allows you to save your current trail to a json file, which can be later loaded.

The final 4 icons are for selection modes, and once clicked change how you interact with the main view of the screen.

The pencil icon turns you into edit mode. Clicking on a mountain allows you to edit the difficulty, length, and name of the mountain.

The branch+ icon turns you into branch addition mode. Clicking on a straight horizontal line in the trail allows you to insert a branch.

The world+ icon turns you into mountain add mode. Clicking on a straight horizontal line in the trail allows you to insert a mountain.

The world- icon turns you into remove mode. Clicking on a branch or mountain in the trail allows you to remove that.

Finally, once you've made some changes and used the save icon to save your changes to a json file, you can load them back up next time using a second argument to main.py. For example calling python main.py basic2.json gives:

What is a trail?

Wiktionary defines a trail as: A route for travel over land, especially a narrow, unpaved pathway for use by hikers, horseback riders, etc.

In this app a trail is a route both over and between mountains.

Motivating the basic components of a trail

The basic trail

The most simple form of a trail is:

1. A line with no mountain on it; or

2. A line with a mountain on it.

Combining Trails

We can combine two trails to form a larger trail:

1.In parallel (Branching paths); or

2.In series (One after the other).

All possible trails can be generated by combining trails according to these rules.

Defining a Trail in Code

We can define a trail more formally using the following rules:

The simplest trail we can have is a line with no mountain.

This is the trail object Trail(None).

Trail takes exactly one argument. It can take one of the following objects: None, TrailSeries, or TrailSplit. These are typed as TrailStore in the code.

We can combine trails in sequence by having a mountain and a trail.

This is the trail object TrailSeries(Mountain(name, difficulty, length), Trail(info)).

TrailSeries takes exactly two arguments.

The first argument must be a mountain, and this is the only way we can add a mountain to a trail.

We can combine trails in parallel by having three trails: two which are in parallel, and the trail that follows.

This is the trail object TrailSplit(Trail(info), Trail(info), Trail(info)).

TrailSplit takes exactly three arguments.

The first argument is the trail that splits upwards

The second argument is the trail that splits downwards

The third argument is the trail that follows once the previous two join together

Seeing it all in action

Note that every Trail object in code has a store, which contains one of the 3 objects above. So for example, we could model the below image with the following object:

trail = Trail(TrailSplit(

   Trail(TrailSplit(    # The top branch

       Trail(TrailSeries(

           Mountain("top-top", 5, 3),

           Trail(None),

       )),

       Trail(TrailSeries(

           Mountain("top-bot", 3, 5),

           Trail(None),

       )),

       Trail(TrailSeries(

           Mountain("top-middle", 4, 7),

           Trail(None),

       )),

   )),

   Trail(TrailSeries(   # The bottom branch

       Mountain("bottom-1", 2, 5),

       Trail(TrailSplit(

           Trail(None),

           Trail(TrailSeries(

               Mountain("bottom-2", 0, 0),

               Trail(None),

           )),

           Trail(None),

       )),

   )),

   Trail(TrailSeries(   # The following branch

       Mountain("final", 4, 4),

       Trail(None),

   )),

))

Which also looks like the following memory diagram (click the image to enlarge):

[TASK] Trail creation & Edit methods

It is highly recommend you fully read and understand the slide "What is a trail?" before continuing.

In this task, you'll be working on:

trail.py

The first task is to add a few helper methods to the Trail definitions in trail.py to support editing the Trails.

In trail.py, you'll find the following methods on a few different classes, already type hinted for you:

remove_branch

remove_mountain

add_mountain_before

add_empty_branch_before

add_mountain_after

add_empty_branch_after

These methods can be used to add and remove elements from the trail.

If this method is defined on the Trail class, you should return a new (or the old) Trail instance, which has completed the action specified.

If this method is defined on a TrailStore class, you should return a new (or the old) TrailStore instance, which has completed the action specified.

For example, suppose we have the following:

a, b, c, d = (Mountain(letter, 5, 5) for letter in "abcd")

empty = Trail(None)

series_b = TrailSeries(b, Trail(TrailSeries(d, Trail(None))))

split = TrailSplit(

   empty,

   Trail(series_b),

   Trail(TrailSeries(c, Trail(None)))

)

t = Trail(TrailSeries(

   a,

   Trail(split)

))

This is represented by the following diagram:

Calling series_b.add_empty_branch_after() returns the following object:

TrailSeries(

   mountain=b,

   following=Trail(store=TrailSplit(

       path_top=Trail(store=None),

       path_bottom=Trail(store=None),

       path_follow=Trail(store=TrailSeries(

           mountain=d,

           following=Trail(store=None)

       ))

   ))

)

While calling split.remove_branch should return the following object:

TrailSeries(

   mountain=c,

   following=Trail(store=None)

)

And calling empty.add_empty_branch_before() should return the following object:

Trail(store=TrailSplit(

   path_top=Trail(store=None),

   path_bottom=Trail(store=None),

   path_follow=Trail(store=None)

))

Note - You don't have to touch the collect_all_mountains function or the length_k_paths function (yet 😝)

[TASK] Traversing Trails with Terrific Tricks

It is highly recommend you fully read and understand the slide "What is a trail?" before continuing.

In this task, you'll be working on:

trail.py

Now that we have defined our Trail objects, and can add extra objects on-top of them, we want to actually walk them!

Now since we have splits in the road, we must decide which path to take. That's where Personalities come in!

A WalkerPersonality is a class that implements two methods:

add_mountain, which allows a Walker to note that mountain they've just walked by

select_branch, which given two Trails as input, decides which of them they will take by returning True or False (True for the first trail, False for the second).

Your task is to, without using recursion, implement the Trail method follow_path, which takes in an argument personality of type WalkerPersonality, and on your trail, calls personality.add_mountain for every mountain on your trail this personality this walker would pass by.

For example, if personality defined select_branch as return True (Always choose the top (first) branch), then in the previous example:

We would call personality.add_mountain with Mountains named top-top, top-middle and final .

For (somewhat) more complicated personalities, see personality.py.

[TASK] Double Keyed Table

In this task and the next, we'll be working on some Data Structures that take inspiration from Hash Tables but make some important changes to the way probing and storage are done. You'll use these structures to solve other problems later in the spec sheet.

In this task, you'll be working on:

double_key_table.py

For this first data structure, we'll be working on a Hash Table that takes two keys rather than one. In terms of storage, this can be thought of as a hash table of hash tables, where a top-level key is used to determine the first position (which hashtable to insert into) and a bottom-level key is used to determine where in this selected hashtable to insert into:

Here, both the top-level and lower level hash tables use Linear Probing to resolve collisions (Note that Het probes from 0->1->2 and "May, Jim" probes from 4->0->1). (The same example is used for test_double_hash.py in test_example.)

Your DoubleKeyTable should implement the following methods:

__init__(self, sizes=None, internal_sizes=None) , create the underlying array. If sizes is not None, the provided array should replace the existing TABLE_SIZES to decide the size of the top-level hash table. If internal_sizes is not None, the provided array should replace the existing TABLE_SIZES for the internal hash tables (See hash_table.py for an example)).

_linear_probe(self, key1: K1, key2: K2, is_insert: bool) -> tuple[int, int], return the:

Index to access in the top-level table, followed by

Index to access in the low-level table

In a tuple.

Your linear probe method should create the internal hash table if is_insert is true and this is the first pair with key1.

keys(self, key:K1|None = None) -> list[K1|K2]

If key = None, return all top-level keys in the hash table

If key != None, return all low-level keys in the sub-table of top-level key

values(self, key:K1|None = None) -> list[V]

If key = None, return all values in all entries of the hash table

If key != None, restrict to all values in the sub-table of top-level key

iter_keys and iter_values: The same functionality as above, but this should return an iterator that yields the keys/values one by one rather than searching the entire table at the start.

Have your code use hash1 and hash2 from the DoubleKeyTable that is already defined.

Have both your top-level table and internal tables resize when the load factor increases past 0.5 (See hash_table.py for an example of this logic) These resizes should occur independently (One internal table may be a different size to another)

__getitem__, __setitem__, and __delitem__. When deleting, if the key1,key2 pair was the only key1 element in the table, you should clear out the entirety of that internal table so that a new key1 with the same hash can be inserted in that position. (See test_delete for more info.)

tablesize(self) . Returns the current

Tip: When creating a new internal hash table, be sure to set table.hash = lambda k: self.hash2(k, table). This ensures any internal table uses hash2 for hashing keys.