Feedback on Module 2 Take 2

[hfboyce]

• Link

All changes discussed added.
I do have a question regarding filtering and if we should teach it with or without .loc[] .
I feel like you'll understand what I mean when you do section 16 followed by 19.
The new version has 29 exercises.

Thank you!

[hfboyce]

[mgelbart]

Feedback on just the coding exercises for now:

3

• Maybe store the URL in a string in the starter code to avoid any possible confusion or copy/paste errors?

4

• Typo: useing
• I'd separate out tasks from hints. "it’s a good idea to see what the delimiter is." seems like it's not a task. Also needs capitalization of the "i". Or you could just combine this with the previous bullet point.

5

• Unlikely, but possible that someone could be confused by "using the Pokemon column name as the index" given that they can't actually look at the Excel sheet. Might want to say using the first column, or maybe "column 0 as the index column".

8

• name, total_bs and type should be in code font

11

• I'm assuming pokemon_special.head(5) would also be an accepted solution by the tests?
• Maybe improve the spacing on the rename line? E.g. add a space after the = and/or remove the space before it?

15

• Need a period after the 2nd task.

18

• Will the tests fail if they use >= instead of > ? Do we want a hint about this?

20

• Could use some rewording. First say that we're creating a new column called base_score, then explain what goes in that column.
• Dataframe -> dataframe

23

• "Create..." -> "Then, create..."
• Inconsistent use of periods at the end of bullet points.
• Are there sub-bullets available for the 3 tasks that are to be chained?
• Typo in the solution: pokemon['defense'] + pokemon['defense']
• Once it gets this complicated, I wonder if we could have even a 1-sentence motivation for why you might want to do this sequence of commands? It feels a bit contrived (because it is, of course) - I wonder if we can mitigate this even somewhat.

26

• Same as my last comment for 23 above. Actually in this case it might be even easier to give an overview of wha is happening. You could start with something like "Find the average speed for water type pokemon in the dataset, by using the following steps:"
• What if they filter by type instead of grouping by type? That should work too. Will the tests allow this? In reality if I were doing this, I'd probably filter. I feel like I might be contradicting an earlier comment here, but what if we just have them display type_means['speed'] instead of type_means.loc['water', 'speed'] so that it's a legitimate use of the groupby?

27

• Again, could use an intro sentence explaining the general goal.
• Again, this feels like it's not a legitimate use case for groupby because you could just filter on legendary == 0. I prefer something a bit more authentic.

28

• Again, could use an intro sentence explaining the general goal.
• Here we have the "semicolon problem" in that it prints out "Text(0, 0.5, 'Mean attack score')". This can be resolved in a few ways:
  • assigning the final line back to attack_plot
  • chaining the set_ylabel onto the previous line
  • renaming the column earlier on instead of setting the y label (but I think it's good for them to learn how to set the y label, so I don't vote for this option)
• Unlike the previous exercises, this feels like a "real" use case for groupby.
• Tiny nitpick: the title says mean attack value and the y-axis label says mean attack score.

[hfboyce]

11. I'm assuming pokemon_special.head(5) would also be an accepted solution by the tests?

Elijah i think can add an "or" condition

23. Once it gets this complicated, I wonder if we could have even a 1-sentence motivation for why you might want to do this sequence of commands? It feels a bit contrived (because it is, of course) - I wonder if we can mitigate this even somewhat

Need to discuss in a meeting

Again, could use an intro sentence explaining the general goal.

At the top of each question I usually have a single sentence that gives a full picture of the question. Were they not showing in these question? It's located above the "Instructions".

27. Again, this feels like it's not a legitimate use case for groupby because you could just filter on legendary == 0. I prefer something a bit more authentic.

What if I asked for type again? is that too much of the same thing? I can also remove this question.

28. Again, could use an intro sentence explaining the general goal.

I'm confused does this not give a goal ?
Let’s attempt to answer the question “Which pokemon type has the highest mean attack score?” by making a bar chart from a groupby object.

[mgelbart]

Feedback on everything else (slides and MC):

1

• 1.2: "classic Excel" -> "Microsoft Excel"
• 1.3
  • need a period after the URL
  • "plain txt" -> "plain text"
  • "It uses the same pd.read_csv() function we saw when reading in csv files." -> "It uses the same pd.read_csv() function we saw when reading in csv files locally."
• 1.4: do we want to say that \t is a tab?
• 1.6: "This means that if that is the case, we need to specify which one we want." -> "If this is the case, we need to specify which sheet we want."

6

• 6.2: The first sentence needs to be rewritten. Remove mention of sheet_name. Split into 2 sentences. Ideally, show some actual function calls read_csv(index_col=0) to remind them how these example arguments are used.
• 6.2: "We are going to introduce a few:" -> "Here, we are going to introduce a few more arguments to read_csv and read_excel:"
• 6.3: "straight forward" -> "straightforward"
• 6.5: "If we load this data without any arguments this is the result." -> "If we load this data without any arguments, this is the result:" (comma and colon)
• 6.8: change period to comma after iloc

7

• 7.1: I got confused by this question. Maybe you could rephrase the question to be something like, "Which one does not change the amount of data read in by read_excel?"

9

• 9.3
  • "and saving the dataframe as an object" -> delete this, I think it will confuse some people
  • "column named" -> "column name"
  • "change it something" -> "change it to something"
  • in general, I prefer a colon to a period for the last line of text right before the code (e.g. "accomplish that:". It seems more inviting. Is this a global change you could implement.
• 9.4: "or the changes will not be saved in our dataframe." I wonder if we could drive this point home by showing code that doesn't do this, and pointing out that df is unchanged, and then explaining that we forgot to overwrite df. It might be more memorable that way. Update: oh, I see you do this in 9.6. But the lesson in 9.6 is a bit backwards because it does look like things worked properly since the columns did disappear. I would redo this a bit to actually show the failure case.
• 9.5: "df.drop() is used when renaming the column labels is not enough and we just don’t want certain columns in the dataframe at all." -> "df.drop() is our verb to delete columns in a dataframe."
• 9.6: on my 100% zoom, I can only see up to Butterfinger in the second df

10

• 10.1: "If we do not assign an object name" is confusing. How about showing the code and asking what is wrong with it. 10.2 is also kind of repetitive. Maybe show one block of code at the top and ask 2 questions about it?

13

• 13.2 "straight forward" -> "straightforward"
• 13.3: "let" -> "let's"
• 13.3: have we taught them iloc[:5]? If so, I'd use that, since it's what I would actually do IRL.
• 13.3: can we come up with a more plausible example? The "fat above 2" is very implausible and thus could confuse people. What about unit conversion using multiplication or division?
• 13.4: this is nice
• 13.6: capitalize "L"
• For 13.5 and 13.6, I think it's important to show the "Before" and "After" on the same slide. Otherwise it's harder to see what is happening.
• 13.7: I would also choose something with nicer numbers where it's more clear in their heads. E.g. converting from grams to mg or something.
• 13.8: great. But, could you show the line of code on this slide as well? Again, it's important for learners to see two things in the same time in order to connect them. You could show the line of code again on the next slide as well, it's fine to repeat it.
• 13.9: "respected" -> "respective"
• 13.12: this should be one of the examples shown previously! This is a general teaching principle that makes a big difference. So you could add a column for sugar/cup. Or else make oz_to_g one of the examples earlier.
• 13.14: nice
• 13.15: I wonder if we could work with a subset of the cereal df with some columns removed. because on my screen the new column is cut off on the right side, which is unfortunate. we really want them to see the new column.

14

• NAN -> NaN
• Maybe add another MCQ here with the correct (single bracket) syntax?

16

• 16.3: "The code can be translated to “select the rows from the dataframe df where the dataframe protein value is greater than 4”." Here I think it's important to use df twice in your sentence because they see df twice in your code.
• 16.3: I actually don't know, this is a real question, should we consider showing them the result of df['protein'] > 4 by itself? It might help or it might make things worse.
• 16.4: colon
• 16.5: colon
• 16.6: before the code, add "Here is how we do it:"
• 16.6: going back to my earlier question, we could go fully down the rabbit hole here, showing the output of each condition and then the & condition. You could make one of your elegant diagrams like you did for elementwise operations in ex 13. Is it worth it?

19

• 19.2: change comma to period before "however"
• 19.2: "we are bringing in our cereal dataset in once again" -> need to remove one of the "in", you have 2
• 19.3: this is too much to take in without seeing any code. I lost focus trying to read this. I would like for us to show 2 code snippets first, one with loc and one with what we were doing earlier. After that, we can start unpacking the distinctions. This slide suffers from top-downness. You've seen David's blog post on this ?
• 19.4-19.5, same problem. The biggest thing I'm missing here is a direct comparison with what we were doing earlier. If the earlier approach doesn't work, that's fine! You can show it failing - that is great motivation for the new thing. So here's an overall structure I suggest. First, say what we want to do (Change Q to Quaker). Next, try the old thing, and see the failure. Then, introduce the new thing and show that it works. Only then, do some sort of high-level discussion/summary like you currently have in 19.3.
  I'd like to review this again once it's updated - please ping me.
• 19.6: "yo" -> typo
• 19.6: is there a problem with the code colouring? I don't think the equals sign should be blue?
• 19.6: "We can now see that 100% Natural Bran's manufacturer value has changed to Quaker but what about the rest of them?" this is potentially confusing because it hints that maybe what we did is still not correct, but in fact it is correct. I would delete this. You could also do head(10) if you want to show more than one.
• 19.6: I wonder if it's worth saying something about how df['mfr'] == 'Q' is referring to rows and that's why we still need the 'mfr' to say which column. This ties into my earlier question about whether we should get into what df['mfr'] == 'Q' returns.
• 19.8: "This" -> "This syntax" ? Or "This approach" ?
• 19.8: some whitespace issues with the -
• 19.8: does this contradict the fact that we're teaching them to use assign to create new columns? 🤔 Should we at least say something about this? Like, you can create columns this way but we prefer assign when possible?
• 19.9: again, maybe we should remove some columns at the start to avoid scrolling.
• In general, exercise 19 seems a lot more difficult than others in this course. It also feels like a lot of memorization of details. Maybe we should discuss? Cut some stuff? Split it into smaller chunks?

21

• 21.3: show the old code first! They will not have the old stuff easily accessible in their brain. Comparisons are key.
• 21.4: comparison is here - great.
• 21.6: maybe we also want a discussion of whether chaining is good or bad. You can say it's a matter of preference and they should optimize readability? And maybe we can suggest they write comments to explain these kind of complicated operations?
• 21.6: missing period

22

• 22.1: unnecessary italics?

24

• 24.2: in the past you used a capital "M" for Module 1 I think?
• 24.3: change comma to period or semicolon before "however"
• 24.3: excellent
• 24.5: this is a bit overwhelming. I hesitate to ask you to change it though because it probably took a lot of work. But a case with a smaller number of groups might have been better. Hmm. What if you split this over multiple slides, so first you just show the input, then you show the G group on a new slide, then add one more, and then show all of them. Would that work? Another problem though is that the text in the group df snippets are a bit too small to see. so maybe you just show 1-2 groups, larger font, and then stack them on top of each other in some way later?
• 24.9: you started with this great motivating question about the mean sugar by manufacturer. I think you should answer that question before moving on to grouping by multiple columns. can we reorder things a bit?
• 24.10: parenthesis -> parentheses
• 24.15: maybe we need a bit more explanatory text here. Perhaps pick two numbers and explain them. E.g. "Look at the '100' in the top left. The interpretation is that, for cases where the manufacturer is 'A', the max number of calories is 100."
• 24.17: "thequestion" -> typo
• 24.19: need closing backtick on `sugar_plot
• 24.19: I would show the plot before putting in the explanatory text. Also, the plot is cut off at the bottom on my screen.
• 24.20: the title is cut off on my screen - font size too big?
• 24.20: maybe a sentence interpreting the results would be nice here? E.g. "If you want high fibre and low fat, consider N's cereals!"

25

• 25.2 missing image 404

[hfboyce]

Discussion for meeting

7.1: I got confused by this question. Maybe you could rephrase the question to be something like, "Which one does not change the amount of data read in by read_excel?"

• I find this wording not in sync with what the solution is though
  "Which argument will assign the index when reading in your data.

9.4: "or the changes will not be saved in our dataframe." I wonder if we could drive this point home by showing code that doesn't do this, and pointing out that df is unchanged, and then explaining that we forgot to overwrite df. It might be more memorable that way. Update: oh, I see you do this in 9.6. But the lesson in 9.6 is a bit backwards because it does look like things worked properly since the columns did disappear. I would redo this a bit to actually show the failure case.

• Does it look like the columns disappear?
  Disregard.

13.3: have we taught them iloc[:5]? If so, I'd use that, since it's what I would actually do IRL.

• I don't think I do. But I could add a remark here for module 1?
  Add in

13.12: this should be one of the examples shown previously! This is a general teaching principle that makes a big difference. So you could add a column for sugar/cup. Or else make oz_to_g one of the examples earlier.

• Quick discussion here!

16.3: I actually don't know, this is a real question, should we consider showing them the result of df['protein'] > 4 by itself? It might help or it might make things worse.

• Discussion of unknown length here!

16.6: going back to my earlier question, we could go fully down the rabbit hole here, showing the output of each condition and then the & condition. You could make one of your elegant diagrams like you did for elementwise operations in ex 13. Is it worth it?

Before I do this, I want to quickly confirm what I am picturing with what you are suggesting.

19.3: this is too much to take in without seeing any code. I lost focus trying to read this. I would like for us to show 2 code snippets first, one with loc and one with what we were doing earlier. After that, we can start unpacking the distinctions. This slide suffers from top-downness. You've seen David's blog post on this ?

and

19.4-19.5, same problem. The biggest thing I'm missing here is a direct comparison with what we were doing earlier. If the earlier approach doesn't work, that's fine! You can show it failing - that is great motivation for the new thing. So here's an overall structure I suggest. First, say what we want to do (Change Q to Quaker). Next, try the old thing, and see the failure. Then, introduce the new thing and show that it works. Only then, do some sort of high-level discussion/summary like you currently have in 19.3.

regular loc or the loc we are doing now? Meeting question.

• Show it failing without loc

19.6: I wonder if it's worth saying something about how df['mfr'] == 'Q' is referring to rows and that's why we still need the 'mfr' to say which column. This ties into my earlier question about whether we should get into what df['mfr'] == 'Q' returns.

Returning topic.

In general, exercise 19 seems a lot more difficult than others in this course. It also feels like a lot of memorization of details. Maybe we should discuss? Cut some stuff? Split it into smaller chunks?

Discuss.

24.5: this is a bit overwhelming. I hesitate to ask you to change it though because it probably took a lot of work. But a case with a smaller number of groups might have been better. Hmm. What if you split this over multiple slides, so first you just show the input, then you show the G group on a new slide, then add one more, and then show all of them. Would that work? Another problem though is that the text in the group df snippets are a bit too small to see. so maybe you just show 1-2 groups, larger font, and then stack them on top of each other in some way later?

I have a backup image!!! I should show you because it's similar to what you are saying.

24.9: you started with this great motivating question about the mean sugar by manufacturer. I think you should answer that question before moving on to grouping by multiple columns. can we reorder things a bit?

Ok so I have an opinion about the double groupby. Discuss in meeting.