UCL / rsd-engineeringcourse

Course materials for Research Software Engineering course.
http://github-pages.ucl.ac.uk/rsd-engineeringcourse/
Other
118 stars 101 forks source link

Functional programming page #114

Closed mattagape closed 5 years ago

mattagape commented 6 years ago
  1. Closures section - it says increment "should have gone out of scope and died at the end of the definition". But I can't see it doing that...have I missed something here?

  2. In "Anyway, this accumulate-under-an-operation process, is so fundamental to..." remove 2nd comma

  3. After "To double all elements in an array:" code block add "To find the maximum value" text before the relevant code.

  4. In print(newton(solve_me, 2), newton(solve_me,0.2)), what are the values of 2 and 0.2 used for?

  5. I'm not sure what's going on with the last plot on this page.

ageorgou commented 6 years ago
  1. Unnamed first section (currying):

    • The running example uses different names as it evolves. Consider renaming define_adder and adder to generate_adder and _add, to match the previous stage (or vice versa).
    • Not sure why add = define_adder "makes things prettier". We just assign the function to a variable, which is not very useful, only complicates things slightly. I agree that add(5)(8) is prettier than define_adder(5)(8), but we could then just use a different name for the function from the start.
    • Perhaps it's worth making it explicit that this pattern can be useful in many situations (e.g. decorators). I don't think the point is clear at the moment.
  2. Map and reduce:

    • "We call this Single Program, Multiple Data. (SPMD)" -> move "(SPMD)" before "."
    • Maybe we should stress that map doesn't return a list (in Python 3), but that you can make a list out of the result
    • "some kind of accumulator": maybe explain a bit more, e.g. "some kind of intermediate result (called an accumulator)". Although this phrasing overlaps a bit with the following segment.
    • This section meanders a bit. I would suggest:
      • Immediately after defining and showing bigger and my_max, state what is now the conclusion of the section: "this accumulate-under-an-operation process, is so fundamental..." and the accompanying code block
      • After that, have a subsection called "Why this is useful" or "Performance improvements", and then explain how map-reduce works on distributed architectures (as it is now).
      • Ideally, add a graph to show what additions happen at each level of the example (like a tree of computations, parallel to the comments - either with the text included in the figure, or side-by-side, if the notebook allows)
  3. Lambda functions:

    • "The syntax here is that these two definitions are identical": this doesn't really make sense. Maybe "The secret is that"? "The key is that"? "The syntax here is such that"? "The syntax here means that"?
    • Have text explaining what the last code block does, as Matthew also said
  4. Using functional programming for numerical methods:

    • Explain what the first example does: "Here, newton is a numerical solver for equations or a way to find roots of functions. The argument we pass it is the function whose roots we want to find ..." (or something similar)
    • Maybe have a more informative print statement: "Starting from {}, the root I found in {}"
    • What is the point of defining solved as a list and then calling plt.plot(*solved)? Can we just call plt.plot(xs, ....) directly?
    • "Sometimes such tools return another function":
      • But here we're defining our own, which we should clarify.
      • And add some explanation of what's happening ("We can use the same pattern to define a function that approximates another function's derivative with a given step size").
      • Also say that straight should be (we expect) a straight line, and that the results match what we expect (with numerical errors because we have a very naive/inaccurate method), and what the plots show.
      • Same comment as above about plt.plot(*solved)
    • "Of course, coding your own numerical methods is bad":
      • Expand a bit, e.g. "because the methods you develop are likely to be less efficient, less accurate and more error-prone than what you can find in existing established libraries"
      • Not sure what the last code block is meant to demonstrate. How to use an existing library method, perhaps?
      • func_derived should return scipy.misc.derivative(func, x), not ...(solve_me, x)
      • I don't see the point of the derived definition in the last block, it could very easily be inlined in the call to newton. Perhaps worth checking the recording to see if this is an example of code that could go wrong? (e.g. having the wrong argument in func_derived)
  5. Overall, some style issues, especially missing spaces in assignments, but also the line splitting in the my_max definition under Lambda functions.