Comment by hatthew
12 hours ago
Am I the only one who feels like this is a rant where the author is projecting their unfamiliarity with numpy? Most of the examples seem like straw men, and I can't tell if that's because they are or if the author genuinely thinks that these are all significant problems.
For example, in the linalg.solve problem, based on reading the documentation for <60 seconds I had two guesses for what would work, and from experimenting it looks like both work equally. If you don't want to take the time to understand the documentation or experiment to see what works, then just write the for loop.
For indexing problems, how about just don't use weird indexing techniques if you don't understand them? I have literally never needed to use a list of lists to index an array in my years of using numpy. And if you do need to use it for some reason, spend 1 minute to test out what happens. "What shape does B have?" is a question that can be answered with `print(B.shape)`. If the concern is about reading code written by other people, then context should make it clear what's happening, and if it's not clear then that's the fault of the person who wrote the code for not using sensible variable names/comments.
Phrasing the indexing problem as a "list of lists of indices" actually makes the behavior pretty intuitive. It's probably an ill-specified goal, but if you wanted to do it, that's probably what it should look like.
I agree this is a rant. I don't think the author is projecting their unfamiliarity here, but they are complaining that numpy is too difficult to learn, especially that style where you avoid all Python loops.
I think my comment on projection was prompted by "which of these is right? No one knows." and "Read that. Meditate on it. Now, notice: You still don’t know how to solve..." when the documentation seems relatively clear (at least as clear as something can be when it's handling 3+ dimensional arrays)