Design document: Follow the instructions in E/DD.08 and record your designs for

Design document:
Follow the instructions in E/DD.08 and record your designs for each of the problems in your Design Document. Make sure to:
List each design in a clearly marked section indicates which question the design belongs to.
For each design make sure to note any details about the question that are relevant to your design, such as the inputs, outputs, any required displays.
Also make sure to detail your tests including all inputs and outputs you’d expect to see.
Each problem should have a detailed plan which outlines step-by-step how you get the required outputs from the provided inputs.
If you divide any problem into smaller algorithms, make sure to detail all of the information for those designs as well.
As a rule of thumb, your designs should include enough detail that anyone else could take your design and implement the same solution without confusion. If you’re questioning if a design is clear enough, ask a TA if they understand your work!
Python template # TODO; My functions
def main():
# TODO; Test my functions
pass
if __name__ == “__main__”:
main()banned techniques are as follows:
Slicing
Built-In Functions
Member Functions
List Comprehension
Sets and Set Testing
Default Parameters
Keyword Arguments
Nested (Local) Function Definitions
While-True or Improper Conditionals
Structure Packing/Unpacking
Multiple Assignment/Return
Out-of-Bounds Indexing
Global Scope and Local Overrides
Containers and other Data Structures
Break, Continue, Yield, Async, Await
E/DD.08 Previously, we designed an algorithm that helped us play a hand of blackjack. One of your friends found out and asked you to help them with a problem they have when playing; namely, there seem to be a couple of cheaters that rig the games so they can always win.
You’ve offered your help by building the algorithm blackjack_checker.
Your friend already started working on this problem, so they have their format describing the cards in a deck. They’ve encoded the cards as two-character strings that describe the suit and face value, respectively. The suit is a single capital letter that is one of the following:
C for Clubs,
D for Diamonds,
H for Hearts, and finally,
S for Spades.
The face values are similarly encoded:
1 through 9 for all the number cards,
T for 10 (so we only use one character),
J for Jacks (worth 10 points),
Q for Queens (worth 10 points),
K for Kings (worth 10 points), and finally,
A for Aces (worth 11 points).
The blackjack game allows someone to choose if an Ace is worth 1 or 11 points, but your friend splits what the players chose by encoding them separately.
Your algorithm should take in a list of strings and first check that all the strings follow the rules above. If the string doesn’t follow these rules or there’s nothing to process, print a message describing the issue and return an empty list.
Next, your algorithm should take this list of strings and create a 2D list of strings, split into chunks of cards that do not exceed 21. For example, if the inputs were a list of H3, DA, and C4, there would only be one hand as 3+11+4 is only 18, but an input of ST, CJ, DA would be two, the first having ST and CJ, and the second having only DA. This will comprise the first row of your output.
Next, you should also be able to check that there is only one card for any suit and face. Some players have been sneakily adding their cards into the deck to cheat through the game, so your friend needs to know of any cards that appear more than once. For example, if someone were to pull the classic all-cards-are-the-nine-of-hearts maneuver (this is also called the “whoops, all hearts” play), your friend needs to have a list with H9 in it so they can check, indeed, that card appears more than once. Hey, your friend never said they weren’t over-reliant on computers, after all… To help them make sure they don’t miss something, all of the entries in this list must be unique. This provides the second row in your output.
For now, your friend would be immensely grateful for just these two things, so that’s all that is expected to be returned: a multidimensional list where the first row is a list of lists, and the second row is the list of all cards that appear more than once.
To help get started, here are two constants that you can use which describe the suit and face values you can expect to see.
SUITS = [“C”, “D”, “H”, “S”]
CARDS = [“1”, “2”, “3”, “4”, “5”, “6”, “7”, “8”, “9”, “T”, “J”, “Q”, “K”, “A”]
You can also use the following basic test examples to guide overall development, but remember that you’ll need to make your own.
Example TestsInputOutput
[“D2”, “CT”, “HK”, “D9”, “SK”][
[[“D2”, “CT”], [“HK”, “D9”], [“SK”]],
[]
]
[“H9”, “H9”, “H9”, “H9”, “H9”][
[[“H9”, “H9”], [“H9”, “H9”], [“H9”]],
[“H9”]
]
[][]or
[[], []]
Note: For the empty input case, either solution will be accepted.
This problem can be solved in many ways, especially since there’s only one function that is required, but don’t be overwhelmed. Start by splitting the problem into smaller pieces and try to answer each of these questions in isolation:
How can I get the value of a card as an integer?
How can I separate a list into arbitrary chunks to get the first row of inputs?
How can I track how many times I’ve seen a card?
How can I then use that data to create a list of all unique cards I’ve seen more than once?
Design your approach before starting. Even if it is initially incorrect, it’s much easier than simply throwing things at the code and seeing what works. Use the debugger and think of how to create and test each more minor component you’re building in isolation before using them together. Remember; we have access to type annotationsnow, so make sure to use those to help catch those pesky bugs!