Week 5: Solutions

This notebook presents solutions to the Week 5 challenges in Data Science, Physics and Chemistry. Unlike previous weeks, these challenges are designed to be more open-ended, so the answers provided below are intended only as examples. There are many ways to approach these questions, and it is not our intention to suggest that the given answers are the “best” approaches, or that a “best” approach even exists.

Table of Contents

Challenge 1: Data Science

To run the solutions for this challenge, you will first need to run the below import statement.

Task 1: Getting Started. Code for this task can be found below:

Demonstrator Notes: The aim of this task is two-fold: (i) to get students familiar with the robot environment and (ii) to get students thinking about how they can use loops to repeatedly move in a given direction. If you see students who are writing "robot.move()" repeatedly, please encourage them to think about how they can make their code shorter by using loops for this task.

Task 2: Sensing Danger. Here is an answer to this problem:

Demonstrator Notes: This question aims to get students thinking about how they can use if statements to navigate the robot environment. It should be noted that students are not asked to stop the robot from turning if it senses a wall to the left or right. The reason that we do not ask for this is that the robot could be in a dead-end (e.g. there is a wall left, right and ahead). If we ask the students to prevent the robot from turning whenever it senses a wall, then in a dead-end the robot will get stuck and the while loop will execute indefinitely. If you see students with this issue, remind them that the question does not ask them to modify the turning behaviour of the robot - it only asks them to modify the call to robot.move().

Task 3: End of the Road. The below code provides a solution to this question.

Demonstrator Notes: Some general advice for this question: - Make sure students have their browser zoomed far enough out so that they can see both the Robot Console and the maze at the same time. - If they haven’t already, advise students to set the robot delay so that the robot moves slowly (e.g. robot.delay = 2). This will allow them to verify that what the robot is printing the correct response in real time. - There are many ways to approach this task; however, one of the most convenient is to count the number of walls around the robot, as counting the wall allows you to handle the dead-end, single-wall and unbordered-square cases immediately. - When students are trying to count the number of walls, let them first write out the robot.sense("AHEAD"), robot.sense("LEFT"),… etc calls one-at-a-time. Once they have done this, point out the repetitive nature of the code to them, and explain why this code might be cleaner using a loop. - When distinguishing between corners and corridors it is easier to list the situations in which you are in a corridor (there is a wall to the left and right, or there is a wall behind and ahead) then the situations where you are in a corner (there is a wall ahead and left, ahead and right, behind and left, behind and right).

Task 4: Turning Back. Below is an example solution for this question.

Demonstrator Notes: This challenge is difficult as it will be drawing on many concepts, some of which are relatively new to the students. It is expected that many students will struggle with (i) identifying the explored and unexplored squares and (ii) choosing randomly from these directions. Feel free to offer more guidance/hold-the-hands of those students that are struggling on this question and stress that it is okay to be struggling at this level. Solving this question should be satisfying, as the robot will move towards the target in a much more directed fashion than in the previous questions.

Task 5: Final Challenge. There are plenty of solutions to this task. Here is just one example:

Demonstrator Notes: Although there are lots of possible algorithms students could use here, the most sensible choice, both in terms of efficiency and implementability, given the setup we have, is the “Hand on Wall Rule”. Encourage students who are unsure to try this rule; compared to part 4 of this challenge, this algorithm is surprisingly easy to implement.

Challenge 2: Physics

This code will load in the challenge data.

Task 1: Clean the Data. Below is an example solution for part (1) of the Physics challenge.

Demonstrator Notes: This is the hardest part of this challenge and it is expected that many of the students will struggle at first. Encourage students to try and break down this question into parts. e.g. useful advice could inclue: - Make sure you can describe the experiment/context in words before starting to code. - Start by considering a string for a single trial. - Write out some string examples on paper first. Make sure you understand the rules for replacing errors before starting to code. - If necessary, try working with some smaller example strings first, e.g. write out test_string = 'ooexx'; test_string2 = 'ooxxe'; test_string3 = 'oeexx' and try to “clean” these one by one.

Also, it is possible for students to get to this point in the course without having worked with dictionaries and lists very much. If a student seems unsure about dictionaries and lists please refer them to the week 1 and week 3 intermediate notebooks for further reading.

Task 2: Detect When Each Bar Begins to Block the Beam. Solution code for part (1) of the Physics challenge is given below.

Demonstrator Notes: It is expected that a large stumbling block for students will be figuring out how they are going to approach the question and, in particular, how they plan to store the results of their computations. Encourage them to think about how carefully about how many time values they will have to store before they start to code:

  • In an invidiual trial, they will have to record the time in seconds every time a bar blocks the sensor. This means they will have one time recorded per bar.
  • The dataset has been deliberately constructed so that different trials use a different number of bars. This is mentioned in the section titled “The Data”.
  • So for each trial, we have one time per bar and the number of bars may vary between trials.

By first discussing the above, it should be easier to motivate potential approaches to storing the time values. For instance, in the above code, a dictionary of lists is used. This approach can be motivated by noting that we have many time values per trial, so it seems reasonable to store these as a list, and then noting that we wish to keep track of which trial each list of times came from, hence the dictionary.

Task 3: Estimate Average Velocities. Example code for this question is given below.

Demonstrator Notes: Compared to the previous, this question is much simpler. However, it is expected that many students may fail to notice that the number of recorded velocities (which are computed as finite differences in distance) will be one less than the number of recorded times (that is, in the above it should be the case that len(times_data)==len(velo_list)+1). If students are experiencing index out of bounds errors, it is worth checking their logic here and writing out on paper an example illustrating how \(n\) datapoints leads to \(n-1\) finite differences. E.g.

\[(2,4,5) \rightarrow (4-2,5-4)=(2,1)\]

Task 4: Estimate Accelerations. An answer to this question is provided below.

Demonstrator Notes: If students have got this far they are likely to complete this question and the next successfully. That said, if reading too fast, some students may confuse \(\tau_k\) and \(t_k\). If students are getting any strange values in their computation, it may be worth checking they have this notation correct.

Task 5: Estimate \(g\). The below code computes the within-trial averages of the acceleration.

The following code averages acceleration across trials.

Demonstrator Notes: The final value output should be 9.825957197907218 (up to python rounding errors). If a student has something wildly different to this, they have likely made a mistake somewhere.

Challenge 3: Chemistry

To run the solutions for this challenge you must first run the below code.

Task 1: Verifying Elements. Here is an example solution to this problem.

Demonstrator Notes: Students will still be building confidence with dictionaries at this point. Try to provide simple examples where possible to help them get to grips with the idea of keys and values.

Task 2: Verifying the Atomic Number. Here is an example answer to task 2.

Demonstrator Notes: Students who skim the text may miss that the number of protons is the atomic number in the periodic table. If they ask about this, encourage them to look back through the text for clarification.

Task 3: Counting Electrons, Protons and Neutrons. Here is some example code for task 3:

Demonstrator Notes: Students who skim the text may miss the fact that the number of protons is the same as the number of electrons. Encourage students who are unsure to CTRL+F for the word electron.

Task 4: Group and Period. Example code for this task is given below.

Demonstrator Notes: This question is laborious but not difficult once you understand the logic. The basic idea is to break the table down into chunks for which the atomic number can be used to predict the group and period. For instance, along the fourth row, the period is 4 and the group is num_protons - 18. If students are struggling with this question, encourage them to narrow their focus to a smaller segment of the table and work with that.

Task 5: Isotope Names. An example solution for this is given below:

Demonstrator Notes: Compared to the previous questions, this is a little easier. Try not to give too much direct assistance on this question, as most students should be able to complete it. The main errors expected on this question are TypeErrors due to students forgetting to cast the string values to integers.

Task 6: Categorizing Isotopes. Here is an example solution to this task.

Demonstrator Notes: This question is much easier if you use the group and period computed in task 4. If students are stuck, encourage them to think about which of the previous tasks might help them here, and highlight that they can use the functions they have already written. To understand the logic of the solution, it helps to draw out a rough periodic table on paper and shade each section covered by successive clauses of the if statement.