# Today I Learned: The Rule of 72

I came over a .pdf on linkedin, which I’m unfortunately unable to find again, containing some lessons of investing from Benjamin Graham’s mentor1. One of them was the rule of 72. The rule of 72 is used to find out how long it takes to double your investment given an annual return rate: $\frac{72}{\text{Rate of Return}} \approx \text{Years to Double}$ I never heard about it before, but it works pretty well for a reasonable range of returns. This plot shows how close the curves are: This made me wonder where this rule came from and how one could come up with such a useful heuristic. It was referenced already in Summa de Arithmetica2 by Luca Pacioli in 1494, also applied to investments. The rule is not explained so it is assumed that the rule predates the book. Fascinating! The number is somehow derived from $$log(2) = 0.693147 \dots$$, which is a transcendental number. Wikipedia also refers to the rule of 69.3, which is more exact. However, it is impractical. 72 is preferable over 69 or 69.3 as it is a mental arithmetic heuristic for the simple reason that 72 is divisible by 2, 3, 4, 6, 8, 9, 12 (and 18, 24, 36, but the heuristic comes from a list of tips for the investor; not the speculator…).

# Upper Bounding the Number of Solutions to a VRP

An interesting puzzle popped out at work last week. One of the things I work on is modeling and solving different variations of the vehicle routing problem (VRP), a generalization of the famous traveling salesperson problem (TSP), which is the problem of finding the shortest tour (or a Hamiltonian cycle) that visits each city exactly once before returning to the starting point. The VRP generalizes the objective to finding the optimal set of routes for a fleet of vehicles (salespeople) that has to visit a given set of customers (cities). We normally solve relatively difficult instances of the VRP with many different side constraints, but the occasional small problem also comes in. One of these small requests caused an issue by flooding the logs due to search getting stuck in a local minimum, moving between two solutions thousands of times per second, logging every move. It moved too fast for any kind of convergence criteria to kick in and end the search. This made me wonder if we could bound the number of solutions worth looking at tight enough to avoid this issue in the future. Brute-force bounds The TSP is often used to illustrate the notion of combinatorial explosion. Given n cities to visit, how many different tours exist?

# Finding references and exploring the language-server protocol

This article follows my journey exploring the language-server-protocol, which somehow led to writing a basic implementation of find-references, a feature LSP implements. If you just want to take a look at my current setup you can find it here. Background I spent some time at the end of last year struggling to setup a smooth Python development environment in emacs. If you make a quick search on how to set up a good development environment for Python in Emacs you can’t get around the language-server protocol (LSP). The amount of information can also be bewildering if you are someone like me, i.e. a data person who somehow fell into software development by chance and necessity who mainly works on very domain-specific stuff within data science and optimisation. All the information and the choices I had to made quickly became bewildering. What is the protocol doing, what is the client doing and how do I connect it to the server? How do I ensure that the backend can access the correct libraries and project modules? A quick search for “emacs lsp” leads you to lsp-mode, which is very well-documented, and the Palantir language server (pyls). However, despite the documentation, I couldn’t make it run smoothly.

# How to Solve Puzzles: An Internal Monologue

An analogy between puzzle solving and software engineering

haakonhr