A2a - FIT1054 - Fantasy Football League
0 | Welcome to the FFL | ⚽
Fantasy Football League
In this assignment, you will embark on an exciting journey of creating a Fantasy Football League system using various data structures and algorithms. You'll design and implement classes to represent players, teams, and the entire football season, ensuring efficient data retrieval and manipulation. This project will challenge your understanding of linked data structures, hash tables, recursion, and iterators, as you simulate a full season of games, manage player and team statistics, and handle dynamic scheduling. By the end of this assignment, you'll have a deeper understanding of how to apply these fundamental concepts in a practical and engaging context.
⚽ Assignment Overview
Create a Fantasy Football League system using linked data structures, hash tables, recursion, and iterators to simulate a season and manage teams and player statistics.
0 Restrictions and Assumptions
. You cannot modify the data structures folder. Similar to A1a you should import these data
structures as part of your solution orthe assignment. Additionally, you should not modify any files in the algorithms folder.
. Please Note: With the advent of A2a, 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 it's
functionality. However, you should not be importing other external Python libraries for storing your collections. Using of any banned instructions (unless specified in the scaffold) will result in the maximum marks penalty of the 'approach' category of the rubric. Note:
the entire assignment can be done without any external libraries.
· You cannot use any built-in sorting algorithms. You must use one of the sorting algorithms in the scaffold OR use a data structure that facilitates sorting algorithms.
· You cannot use generative AI, machine learning, or any other form. of AI software.
· You cannot use any hard-coded constants, except the ones provided to you in the constants class. If you need to use a constant, please add it to the constants class.
. You cannot access the internals of ANY data structures or any classes except the custom classes that you edit in the tasks. You can only access the methods of the data structures that are
provided to you in the scaffold. Each use of the internals of a data structure will count as a major mistake and will lose at least half of the marks for the task.
0 Link to the GitHub Scaffold
⚠ Important Notes
As you go through the content of the unit, you may realise that the ADT choices you made for some of your previous tasks in this assignment may not be optimal. Hence, it is important to go back and change them if you feel this makes the solution optimal and/or more elegant. Remember that you are being marked on the quality of your code, including scalability and choice of ADTs.
Complexity Notes [Important]
You must adhere to the complexity bounds given in this assignment. Failure to do so will attract hefty penalties, even if your code works.
0 | Structure of the Assignment | 0
This assignment is structured around building a comprehensive Fantasy Football League system by implementing several interconnected classes and data structures. The primary goal is to simulate a football season, managing teams and players while ensuring efficient data retrieval and
manipulation. The assignment focuses on utilizing linked data structures, hash tables, recursion, and iterators.
Classes and Their Roles
. Player Class:
The Player class represents individual football players. Each player has attributes such as name, age, and position (e.g., goalkeeper, defender, midfielder, striker) which is unique (i.e., a player can only have one position).
o Players also have associated statistics that refl ect their performance, such as games played, goals scored, and assists made.
The Player class includes methods to update and retrieve these statistics efficiently. Team Class:
The Team class encapsulates a collection of players and the team's overall statistics.
o Players are stored based on their position, ensuring quick access and management. If multiple players occupy the same position, they are linked together, creating a chain of players for each position.
o The team statistics include metrics such as代 写 FIT1054 - Fantasy Football League games played, wins, draws, losses, goals for, goals against, goal difference, points, and results of the last five games.
Methods in the Team class manage adding and retrieving players and updating team statistics.
Season Class:
The Season class manages the entire football season, including the teams participating and the schedule of games.
o It holds a collection of teams and provides methods to add or remove teams from the season.
o The game schedule is dynamic and can change at any given game week.
The Season class includes functionality to simulate the entire season, individual games, and update team statistics based on game outcomes.
o Additionally, it maintains a leaderboard to track team rankings based on their
performance throughout the season. Award Class:
o The Award class is used to manage the player awards for the season. o It holds a:
reference to the season
the player stat used to allocate awards
the number of players from each team that are receiving the award.
o Additionally, it maintains a leaderboard to track player awards based on their
performance throughout the season. · Interconnections:
Player and Team: Each Team object holds a collection of Player objects, connecting individual players to their respective teams. This relationship is crucial for managing and updating player and team statistics as the season progresses.
Team and Season: The Season class contains multiple Team objects, linking the teams to the overall season framework. The schedule of games involves these teams, and the season simulation updates team statistics based on game results.
o Award and Season: The Award class will use the season object to get the players from each team to generate their stats and calculate the final player leaderboard.
You will learn more about these classes and methods in the tasks that follow. Remember! You are on a continuous learning journey and if at any stage you feel that a particular data type would be better suited for a task, visit your previous tasks and change as necessary!
Player And Team Stats
Over the next few tasks you will learn about team and player statistics. These can be found in the constants .py file and are divided into two enum classes. Here is an explanation of each of the statistics.
Player Stats
1. GAMES_PLAYED - Games played by the player this season
2. GOALS - Goals scored by the player this season
3. ASSISTS - Assists provided by the player this season
4. TACKLES - Tackles made by the player this season
5. INTERCEPTIONS - Interceptions made by the player this season
6. STAR_SKILL - A star rating of the skills of the player (out of 5 stars) this season
7. WEAK_FOOT_ABILITY - A star rating of the weak foot ability of the player (out of 5 stars) this
season
8. WEIGHT - The weight of the player (in kg) this season
9. HEIGHT - The height of the player (in cm not freedom units) this season
NOTE - The STAR_SKILL , WEAK_ FOOT_ABILITY , WEIGHT , HEIGHT should all be initialised as 0 at the start. These will be randomly generated by the tests.
Team Stats
1. GAMES_PLAYED - Games played by the team this season
2. POINTS - Points accrued by the team this season.
3. WINS - Number of wins by the team this season
4. DRAWS - Number of draws by the team this season
5. LOSSES - Number of losses by the team this season
6. GOALS_FOR - Goals scored for the team this season
7. GOALS_AGAINST - Goals scored against the team this season
8. GOALS_DIFFERENCE - Goal difference between scored vs conceded (calculated as GOALS_FOR - GOALS_AGAINST )
9. LAST_FIVE_RESULTS - The last 5 results of the team this season with the oldest one at the front. This CAN NOT be stored in an ArrayR. For example, if (the most recent) results of the team are W W L D W then this should hold the appropriate enum values: GameResult.WIN,
GameResult.DRAW, GameResult.LOSS, GameResult.WIN, GameResult.WIN. If the team has played less than 5 games, then this should contain the results of however many games the team has played.
If the team has played NO games this season, then getting this statistic should just return None .
NOTE - GAMES_PLAYED , POINTS , GOAL_DIFFERENCE and LAST_ FIVE_RESULTS are stats that WILL NOT be
manually entered. These need to be calculated as a result of one of the other stats updating. For example - a WIN should update the wins by +1, games played by +1 and should add a result to the LAST_ FIVE_RESULTS . It should also update the points by +3.
Constants and Enums
This assignment includes several enums and constants that are used throughout the assignment. These can be found in the file constants .py .
This file is dynamic and you can define your own enums and constants in this file if required. Here is a description of the constants and enums provided:
1. GameResult - This enum contains the possible outcomes of a game. The value of the outcome is the number of points the team gets for achieving that result:
- WIN : 3 points
- DRAW : 1 point
- LOSS - 0 points
2. Constants - This enum contains constants that you may find convenient for your
implementation. These may or may not be useful for you. As in A1a, the constants should be treated as variable while programming as well as while performing complexity analysis.
1. SEASON_LENGTH : number of weeks the season runs for.
2. TEAM_MIN_PLAYERS : minimum number of players in the team
3. TEAM_MAX_PLAYERS : maximum number of players in the team
4. MAX_NUM_TEAMS : maximum number of teams to play in a season
3. PlayerStats - This enum contains the various statistics associated with a player (explained in the previous slide)
4. TeamStats - This enum contains the various statistics associated with a team (explained in the previous slide)
5. PlayerPosition - This enum contains the position of the player (names specify what position they play but if you are keen to learn, you can follow this link).
6. ResultStats : This enum contains the statistics returned by a game's result:
1. HOME_GOALS : goals scored by the home team
2. AWAY_GOALS : goals scored by the away team
3. GOAL_SCORERS : an ArrayR of player objects that scored a goal (each mention is worth 1 goal)
4. GOAL_ASSISTS : an ArrayR of player objects that assisted a goal (each mention is worth 1 assist)
5. TACKLES : an ArrayR of player objects that made a tackle in the game (each mention is worth 1 tackle)
6. INTERCEPTIONS : an ArrayR of player objects that made an interception in the game (each mention is worth 1 interception)
0 | Task 1 The Player Class
The Player Class
You must now modify the player .py file to implement the Player class with the following attributes:
· name - a string representing the name of the player. The name is given in the init method. You can assume the name is unique.
· position - a position is given by the PlayerPosition in constants .py . The position is given in the init method.
. age - an integer representing the age of the player (must be 18 or higher). The age is given in the init method.
. statistics - a data structure that holds the values of statistics relevant to the player. A list of statistics is given in the constants file as PlayerStats and on __init__ these stats should all be set to 0.
and the following methods:
· reset_stats - resets all PlayerStats stats to 0. · get_name(self) - returns the name of the player.
. get_position(self) - returns the position of the player.
. get_statistics(self) - returns the statistics of the player.
. __setitem__ (self, statistic: PlayerStats, value: int) - updates the value of the statistic passed as statistic .
. __getitem__ (self, statistic: PlayerStats) - returns the value of the statistic passed as
key .
Methods __str__ and __ repr__ are included (though not implemented); these are optional to complete but are highly recommended.
· Complexity analysis is not required for __str__ and __ repr__ .
0 | Task 2 - The Team Class
The Team Class
You must now modify the team .py file to implement the Team class with the following attributes:
. number - A unique number for this team. The fi rst team number should be 1 (then 2, and so on).
· name - a string that refers to the team's name. The name is given in the init method. You can assume the name is unique.
· statistics - a data structure that contains statistics related to the Team class. These are
similar (but no the same as the player stats). A list of statistics is given in the constants file as TeamStats and on __init__ these stats should all be set to 0 (with the exception of the
LAST_FIVE_RESULTS statistic, which should be initialised to an empty container of the ADT of your choice).
· players - a collection of Player objects grouped by PlayerPosition , initially provided to
__init__ as an ArrayR of players and then stored with an appropriate ADT to ensure they appear by the player's position (see image below). For example, all goalkeepers are saved together and all midfielders are saved together. To see the possible positions, you can refer to the
PlayerPosition enum. You can assume that the enum is exhaustive and we will never have another position that doesn't exist in the enum.
HINT - To get the number of values that exist in an enum class EnumClass , you can call len(EnumClass)
NOTE - The order of the players is important. For example - if you get two goalkeepers, where gk1 arrives before gk2 to the team, then gk1 needs to be before gk2 .
See an example of the structure below:
Given an collection of players and their positions in brackets for visual purposes.
The team class must also implement the following functions:
· reset_stats - resets all TeamStats stats to the state they were in during initialisation.
. add_player(self, player: Player) - This method adds a player to the team. The player must be added after the already existing players at that position in the team.
. remove_player(self, player: Player) - This method removes a player from the team.
· get_players(position: PlayerPosition = None) -> Collection[Player] | None - Returns only the players in a team held that match the PlayerPosition provided return these players
objects in any of the data structures provided to you. The order in which a player was added to the team is important also within this method and is checked by the tests. If the value of position is None, then it should return ALL players in the team. Do not affect the team
instance variable after calling this method, i.e. do not lose data/change ordering after this
method is called. It should return None if no players match the provided criteria / the team is empty.
For example - if we called get_players() on the team in the example above, it should return a collection of Players in the following order:
[p1, p4, p7, p6, p9, p3, p8, p10, p2, p5]
So; goalkeepers followed by defenders followed by midfielders followed by attackers. And the order of the players is as they were added (if the position is the same).
. get_number(self) - Returns the team's number. . get_name(self) - Returns the team's name.
. get_statistics(self) - returns the statistics of the team.
· get_last_five_ results(self) -> Collection[GameResult] - this method returns the last 5 results in the order specified on the Player and Team Stats page these results are returned in a data structure of your choice similar to get_players . The order of the match results is checked by the tests to ensure it matches the given requirement please.
. __setitem__ (self, statistic: TeamStats, value: int) - this method updates the value of the statistic that is passed as the statistic . Consider the cascading effect of updating a
statistic as well. For example - if we are updating the number of wins, then you need to update the points as well as the last 5 games statistic as well.
For example - if statistic is WINS and the value being passed is n + 1 and the current value of WINS for the team is n, then we do the following:
o Update the number of WINS by 1
o Update the number of GAMES_PLAYED by 1 (this should be applied to the team and every player in the team).
o Update the number of POINTS by adding the value of GameResult.WIN.value (which is set to 3 in the scaffold)
o Add the result to the LAST_FIVE_RESULTS as the latest result.
NOTE - You can assume that setitem will always be additive, i.e. we will never call this method to 'reduce' the statistics in any way, it will always add to the existing value.
You should also consider updating GOAL_DIFFERENCE , when updating GOALS_FOR or
GOALS_AGAINST .
You can assume that setitem will never be called on GOAL_DIFFERENCE ,
LAST_FIVE_RESULTS , GAMES_PLAYED , POINTS directly as these get set as a cascading effect of other statistics.
· __getitem__ (self, statistic: TeamStats) - this method returns the value of the statistic that is passed as the statistic .
· __len__ (self) - this method returns the number of players in the team
Where possible you should aim to minimise time complexity of the above methods in order to receive full approach marks.
__str__ and __ repr__ methods for the team class have been provided for you these are optional to complete but are highly recommended.
· Complexity analysis is not required for __str__ and __ repr__ .
#D | Task 3 - A couple of curious hash tables | ┳┳
More Hash Tables - Introduction
The idea here is to provide two improvements to our Hash Table implementation. You can complete
the whole assignment without using these implementations, but you may find it better to change your previous tasks to use these Hash Tables instead of just using the LinearProbeTable
implementation.
In this task we ask that you explore two key factors of the Hashtable ADT;
. Collision resolution.
. Hash functions and their performance.
To do this you will make two implementations of the Hash Table. Each will be held in a different class within the files hashy_perfection_table .py and hashy_step_table .py you already have as part of the assignment's scaffold.
The HashyPerfectionTable
In this Hash Table, we will consider a niche example of when we already know the keys and define a Hash Table with a perfect Hash Function. For simplicity's sake, we will consider only the values that exist in the PlayerStats enum, and no validation is required
The hash function for HashyPerfectionTable should return a unique position in the table for each of the stats, which means the following is true and should be true for all keys compared via their hash
values:
sample = HashyPerfectionTable()
sample.hash( 'Games Played') != sample.hash( 'Goals For') # True
In addition to the hash value's output being different for the given keys they should also not map to
the same position in the HashyPerfectionTable internal array.
You must modify the hash method in file HashyPerfectionTable .py to achieve this. You may increase the table size from 13, but by doing so, you probably will not receive full marks for the approach.
For example, the following would receive 0 marks for this section
def hash(key: K) -> int:
if key == "Games Played":
return 1
elif key == "Goals For": return 2
elif key == "Assists": return 3
# ...
The HashyStepTable
Our second strategy is to modify the LinearProbeTable in a file called hashy_step_table .py . Our current implementation uses a fixed step size of 1 when probing through our table. Your task is to implement a new hash function that will dynamically determine the step size based on the key. Your probe function should use this step size rather than using 1 as the step size.
You will need to implement the following methods to make Hash Table functional.
· hash2(self, key: K) -> int - Used to determine the step size for our Hash Table.
· _hashy_probe(self, key: K, is_insert: bool) - Find the correct position for this key in the Hash Table using linear probing. This method should use the hash2 method to determine the step size when probing.
· delitem(self, key: K) -> None - Deletes the item from the Hash Table using a key. You should use lazy deletion / sentinel deletion to implement this.
o More information can be found in the pre-reading in Week 7 on slide 61.
Make sure you revisit the _hash_probe method to ensure your implementation works with the new deletion approach and makes appropriate optimisations.
· _ rehash(self) -> None - Used to resize the table when it becomes too full (see setitem ).
To get full approach marks your HashyStepTable should be relatively performant and hashstep should
return a variety of different step sizes for an input of unique keys, as well as the table being fully functional for all inputs just as the LinearProbeTable is.
标签：__,statistics,Fantasy,season,Football,should,player,FIT1054,team From： https://www.cnblogs.com/qq---99515681/p/18418460