00ajcr

There's a Cython implementation (the .pyx file). The Cython code is compiled to C code (then that C code is compiled).

Less ambitious than where?

I don't think UK people are inheritantly less ambitious than anywhere else, but the very low social mobility here has always dragged down potential for some, while the punishing austerity and lack of investment over the past decade has limited other people's opportunities further.

My interpretation of the point in the blog post was that explicitly spelling out variable names makes APIs and the underlying code much more accessible to a wider audience.

Sure, there'll be a subset of users of these libraries that have read ML/textbooks and are familiar with what η means in this context.

Today, many (most?) users of ML libraries will probably not know what η means without looking it up. Adhering to mathematical notation puts up an unnecessary barrier to using the API/code and ultimately limits wider engagement/collaboration.

To attract a bigger slice of the ML community, choosing names that the ML hobbyyist can read, understand and use without pause is the better path forward.

Aside from significant whitespace (which I suppose takes a little getting used to), is there anything that marks out Python's syntax as particularly rigid compared to other languages?

I'm struggling to understand what the author is trying to argue here.

To broadcast operations (such as addition) between arrays in NumPy, trailing dimensions have to be equal (or be of length 1).

In the example given above the 3D array and 2D array have shape (lengths of dimensions):

   (2, 3, 4)
      (2, 3)

That is - the suffixes do not agree (4 != 3 and 3 != 2) and NumPy raises an error.

However, for the same operation in J the prefixes agree:

   (2, 3, 4)
   (2, 3)

and the addition gives the expected result.

To add the arrays with these shapes in NumPy, one method is transpose each array (reverse order of the dimensions), add these arrays, and then transpose back:

  (a.T + b.T).T

For fans of crime/detective novels, I would not hesitate to recommend 'The Chain of Chance'.

Utterly gripping, fascinating, and a gateway to Lem's sci-fi works.

I think it's the `--skip-string-normalization` flag which means "Don't normalize string quotes or prefixes".

Surely the [sic] annotations are to indicate that the quotations are unchanged from the original source text, which contains somewhat archaic language and misspellings of words when compared to modern English.

Philip Guo has an excellent set of video lectures on CPython internals, which includes an overview of parts of ceval.c: http://pgbovine.net/cpython-internals.htm

Useful tips and a nice skeleton!

There's also a great guide to cleaning bones from animals (in various states of decay) on the blog Jake's Bones that I've referred to a couple of times: http://www.jakes-bones.com/p/how-to-clean-animal-bones.html

I started writing a '100-pandas-puzzles' set of exercises here: https://github.com/ajcr/100-pandas-puzzles

There's also pandas_exercises by Guilherme Samora (https://github.com/guipsamora/pandas_exercises) which is very good - it's split across multiple notebooks and is more extensive than my repo.

There are some nice exercises here, good work.

For question 48 it might be simpler to just write

  np.sort(a)[-5:]

instead of using argsort() and then using fancy indexing. Better yet, use

  np.partition(a, kth=-5)[-5:]

which scales linearly with the size of the array.

Also, the one-hot encoding puzzle (51) would be more efficiently solved using

  (arr[:, None] == np.unique(arr)).view(np.int8)

In general, `for` loops over NumPy arrays should be avoided where at all possible.

No! Never do this in Python.

You are making the flattened list by continually concatenating the smaller lists. Each concatenation creates the new bigger list from scratch; the flattened list does not grow dynamically. This is quadratic-performance bad.

Use `list(itertools.chain.from_iterable(...))` instead.