I, for sure, spend equal if not time writing the data flywheel code compared to architectural changes.

This has been bugging me for awhile, but I haven’t had time to sit down and write about it until now. In my mind there are three things that makes coming up with a good take about this (and also implementing it) hard:

1. This may be a problem that’s solved in much of the frontier labs (I would argue more because of workflow optimizations that sidestep the problem, see below)
2. The “solution” to the problem also seem extremely person-dependent, so it seems hard to make an overall suggestion.
3. Many people write it off as “necessary engineering”

I don’t purport to have a solution to the pipes problem here, but I want to spend a little time now to reflect about what I have been thinking about while spending days at the office writing pipes.

Woof. As I begin to write this I should add that this unit is going to be conceptually dense. Though we are teaching one particular algorithm (incidentally, named, REINFORCE), the world of reinforcement learning is build by one, if not many, very advanced treatments in maths.

So if anything, I would focus on getting the conceptual flavor of how these problems are formulated and discuses. If you can be along for the mathematical and algorithmic journey, then even better — but by no means required or expected… There’s still lots for all of us to learn together.

Why are Todo Lists (a.k.a. personal productivity systems) so hard to build well?

I’m genuinely curious. I was listening to the last episode of Cortex, and one of the hosts (CGP Grey) brought up a similar point regarding personal productivity platforms. OmniFocus, the reigning champion of the industry for professionals looking for a deeply customized system, has been staggering in their ability to ship the next version of their application. Much of the market consists of various different packagings of the same offering. Grey’s thesis of these platforms essentially boils down to this:

For the past 20 years, semantic indexing sucked.

For the most part, the core offerings of search products in the last while is divided into two categories:

1. Full-text search things (i.e. every app in the face of the planet that stores text), which for the most part use something n-grammy like Okapi BM25 to do nice fuzzy string matching
2. Ranking/Recommendation things, who isn’t so much trying to search a database as they are trying to guess the user’s intent and recommend them things from it

And we lived in a pretty happy world in which, depending on the application, developers chose one or the other to build.

Hello! Welcome to the series of guided code-along labs to introduce you to the basis of using the PyTorch library and its friends to create a neural network! We will dive deeply into Torch, focusing on how practically it can be used to build Neural Networks, as well as taking sideroads into how it works under the hood.

Getting Started

To get started, let’s open a colab and import Torch!

import torch
import torch.nn as nn

The top line here import PyTorch generally, and the bottom line imports the Neural Network libraries. We will need both for today and into the future!