Dear all,
I had sent two mails to the webmaster address a while ago and wondered if I was wrong in pointing a few things out. Still learning, so curious about it!
Best
Carsten
Hi Carsten,
Thanks for your message. I should get anything sent to webmaster. I did a search but couldn’t find anything from you. Sorry if it was lost. We’re in the process of switching everything over to AWS, which should be more reliable.
Do you mind to repeat your comments on this forum? All feedback is appreciated.
Regards, John.
Hi John,
No worries, below you’ll find a list. First of all, however, I wanted to thank you for making your project available online. It’s exactly what I had been looking for and the level of difficulty as well as the speed of progression is spot on!
My intention with the comments was as follows: Prior to getting started on Python, I had primarily worked with Stata as I’m assuming most - or at least a lot of - people do. Thinking that others with the same background would potentially stumble across the same issues, I wanted to share them.
####1.3. typo (I think)
It says “Line 9 indicates that the list epsilon_values is the object that should be returned to the calling code” (it’s on page 42 if displayed in PDF format).
I think it would need to be “line 10”, or at least that is where the object to be returned is defined as far as I understand.
####1.4 (“Exercises”)
Prior exercises used to be instructed in a way that only specific functions were supposed to be used. Hence, I began doing this section’s exercises thinking just in terms of the core functionalities I had gotten to know thus far. While the sum() function is straight-forward to understand and use, it has previously been applied only once in a code example on bools and was not specified any further. As a result, I began trying to solve the exercises without using it although the solutions make heavy use of it. My suggestion would be to add a note on top of the exercises along the lines of "Note: you may want to use the sum() function“ so that readers wouldn’t spend too much time running in wrong directions.
####1.4 ("comparisons section“)
Getting the content of below box took me a while. In principle, the issue was that an integer being evaluated as True was at the time a new concept to me. While it is a perfectly understandable convention, I didn’t get it straight away from what was written and instead began trying to make sense of it along the lines of what I knew from before.
Not having had a lot of routine looking code like this, I missed that it just says „if 42“. Instead, I read it as if it would say "if x==42“. I was then further confused by the fact that the numbered Inputs and Outputs continued to increase steadily from the prior box (51) to below box (52-55), causing me to wonder when x had been redefined as it was previously defined to equal 1.
I am well aware that this is entirely me misreading the code, but as I would think of my prior software experiences as very close to the one of the average user that might consider switching to Python, clarifying this section a little more could increase readability.
First, I could e.g. imagine a comment on the line of „In [52]“ to clarify that it’s just a integer (string?) in this expression.
Furthermore, the explanation given underneath the box explains only the cases where the expression is evaluated as False at length. The cases for when it’s True are, however, only given by contrasting it to the previous line („All other values are equivalent to True“). I think that adding a further sentence or half-sentence to the same bullet on why exactly 53 evaluates to not zero and, consequently, yes would clarify what’s going on greatly for a newbie reader.
Additionally, I would suggest amending the phrase "empty sequences/containers (strings, lists, etc.)“. An idea would be to for instance write "empty sequences/containers (strings such as “”, lists such as , etc.)“ to make the contrast between empty and non-empty even more clear.
Bildschirmfoto 2016-07-10 um 20.10.12.png
####1.4 ("Combining Expressions“)
Upon first reading, I thought that the 2nd and 4th bullet would mean the same and were double. Placing the 2nd and 4th bullet directly after one another and/or highlighting the words function and object in cursive could make sure others understand it correctly straight away.
Bildschirmfoto 2016-07-10 um 20.15.16.png
####1.6 ("Name Resolution“)
The exact hierarchy of the enclosing namespaces (innermost to outermost vs. outermost to innermost) could be specified.
####1.7 ("An Example“)
I would suggest explaining what “nan” stands for. The whole concept of OOP is at that point still something that one is beginning to grasp and mentioning it as “just” being a NumPy object was a little unsatisfying for me. On top, it’s a little confusing because I thought of it as more of a missing value (at least that’s the interpretation I got from Wes McKinney’s book Python for Data Analysis, which I’m also reading at the side).
####1.7 ("Example 2“)
Similar to the issue raised in 1.4. I could think that a further line explaining why it becomes infinite underneath the box would add clarity.
####1.8 ("Mutability and Copying Arrays“)
A typo underneath the first box: "…which some people find seem to find shocking“
####1.9 („Multiple Plot on One Axis“)
Loc and Scale show up here for the first time, but are only explained in 10.10. A hint could be added that this is not important to understand at this stage and will be explained at a later point.
The word “interpreter” shows up a lot, but is not explained. The index of the PDF links to page 91, which however isn’t the first instance of the word.
Here are the screenshots that unfortunately didn’t upload properly on my first try. In order of appearance in above post:
Hi Carsten,
Thanks for all these comments! They are greatly appreciated.
I’ll work through them carefully over the next couple of days. If I have thoughts or responses I’ll get back to you.
Regards, John.
Hi Carsten,
I worked through your suggestions and made a number of changes. Thanks again. You obviously read the document carefully.
My changes will show up in a week or so, when we upload a new version.
We do want to provide more assistance for people coming from Stata, by the way. To date a lot of what we’ve done is in dynamic macro. But it would be nice to get some more lectures together on empirics.
If there’s anything in particular you’d like to see on the site please let us know, and we’ll see what we can do.
All the best, John.
Hi John,
I think that would be an excellent idea. As it is, the script makes a great case for Python based on its universality, data management capabilities, and quality of graphs, but it lacks persuasiveness when it comes to some routine tasks and presenting e.g. Python as a one-stop-shop.
If part of the project’s aim is to increase the user base, one such area would be output tables. While it constitutes only a small part of the work in original research, it’s annoying to spend more time than necessary on it during recurring tasks. I can imagine that providing examples of output tables (e.g. first sample summary statistics, then another one for publication-style regression output) could be helpful. Basically to show that you can achieve what Stata’s outreg2 command does, except much more versatile. Furthermore, showing how to export it to Excel could be valuable. The way I have gotten to know policy-related work, Word is what is used for eventually putting together the final documents.
While not necessarily quantitative economics, I think that adding something like this could sway people in favour of giving a programming language a try for their department’s day-to-day work.
I’d be happy to help if you’d ever need someone to proof-read for comprehension or the like.
Best
Carsten
Hi Carsten,
That’s a great idea. Very specific too, which is really helpful. (I’ve had similar thoughts in the back of my mind but wasn’t quite sure of the details.)
We have a list of things we need to implement so it might take us a little while, but we’ll get there.
Regards, John.