Browse Month

March 2017

On Paying Oneself First

The expression “pay yourself first” is one very frequently put forth in personal finance circles. In practice, this often involves automatically rerouting some amount of money into a separate savings or investment account whenever a paycheck comes in. Besides the mathematical benefits (compounding; to some extent, risk mitigation via cost averaging if one’s investing), I can see how the approach could be useful psychologically (in that it reflects a shift in one’s mindset concerning money, as well as a conscious prioritization of savings and capital growth). I’ve personally been following this, though I’ve been investing the money into a portfolio of equity trusts and index funds (I’d recommend having an emergency pot to sustain a few months’ expenses first, though).

I see no reason why this can’t be generalized beyond money, though, especially since we do have to manage far more important scarce resources. In particular, I’m looking at time. I’ve received feedback that I tend to slant towards being outcome-oriented, and this does mean that if an important project is lagging but I see a way to recover, I’ll tend to vigorously pursue it – it’s thus not too difficult for me to end up spending 70 or even more hours a week on said project (or even 90-plus, as I did in second year at Imperial). I’ve learned that this is unsustainable, but for me it’s still not the easiest decision to drop something (to the point where a friend commended me for actually using some of my leave during the industrial placement!).

If we look at time in the same way, we get 24 hours a day, or 168 a week; things like sleep are of course important, but I tend to see them more as bills or taxes that need to be paid (not paying them tends to lead to interest!). So paying myself first would involve reserving some time for something else; I’d propose personal learning and development as a good candidate for this.

This is perhaps unsurprising; I suspect that if I polled people as to what “investing in oneself” entails, many answers concerning education would be forthcoming. Like bonds and equities (hopefully), developing one’s skills can lead to future payoffs. I do tend to partition this time into roughly three different domains:

  1. Technical development – e.g. paper reading, programming contests, code katas. These are likely to feed back in to my software engineering work. I’d probably consider these similar to equity income mutual funds; they (ideally) grow in value reasonably steadily and generate nice payoffs along the way too.
  2. General professional development – e.g. writing, finance, tax. Useful for both software engineering work (from what I can recall, I’ve written a lot of docs) and also for managing my own professional matters. Again, these are generally useful; perhaps they have smaller immediate payoffs than technical development, though I tend to think of them as also very important in the long run. Perhaps these would be more similar to a growth-focused fund then? Or even BRK-B (or BRK-A; we’ll get to that but I don’t have a quarter of a million quite yet!)
  3. Random development – singing, photography, etc. These are generally quite fun (I do also enjoy software engineering, writing and finance, but they like all other domains tend to have diminishing marginal returns), and might suddenly explode into usefulness or value given the right conditions. Perhaps these are like emerging market equity funds that are focused on a specific country. There’s certainly a fair bit of variance, but the returns can sometimes be impressive. (If one wishes to take the metaphor even further, deeply out of the money options could be more accurate; they certainly add a bit of fun to a portfolio, too! That said, I have no direct experience with option trading.)

Of course, money and finances are an important thing to manage, and I believe that paying oneself first is a good strategy there. However, it does feel to me that time is even more important. My admittedly equity-heavy portfolio lost around 6 percent during the US election jitters, and this is a portfolio which I’ve built up over the course of about a year and a half now – yet I didn’t feel much (I was expecting a further fall post-Trump win, though in the end the markets rallied). I’m the kind of person who can get annoyed if I find that a day was wasted – let’s not even get started on my reaction to 6% of 18 months (just over a month; 32.87 days). Of course, we have to be careful about jumping to conclusions about what constitutes waste or loss, but I think the point that I find loss of time more painful than loss of money (at least at a small-percentage scale) still holds.

Taking Risks on Rotations

I haven’t owned a gaming console since the Playstation 2, mainly because I’ve found PCs to be sufficient for my own purposes and I don’t do very much gaming in the first place. I already have a pretty good PC for some of my own work (such as programming and some image/video editing I’ve done in the past). Nonetheless, I do enjoy watching a few YouTube channels which feature playthroughs of games with commentary, and I’ve certainly seen a lot of news regarding Nintendo’s latest console, the Switch.

One of the launch titles for the console, 1-2-Switch is a minigame collection which largely serves to demonstrate the capabilities of the Switch’s controllers (or “Joy-Cons”). The controllers have buttons, motion sensing capabilities, a camera (“Eating Contest”) and some kind of precise vibration (“Ball Count”). Most of the minigames seem simple and somewhat fun, as well as relatively balanced (in fact most games don’t really feature a way for players to interfere with one another – several others also have players’ roles over the course of the entire minigame being largely symmetric). There are a few that seem unbalanced (“Samurai Training” – assuming equal probability of success the first player has a greater probability of winning), though there was one that was clearly unbalanced in favour of the second player, that being “Joy-Con Rotation”.

The game invites players to rotate their controller about a vertical axis as much as possible, without otherwise disturbing it (e.g. by tilting the controller) too much. Scores are measured in degrees of rotation, with “unsuccessful” turns (e.g. too much alternative movement) scoring 0. Players get three rotations in turn, and then the score from their three turns is added up. In a sense this gives the second player an advantage; on his final turn he needs to know how much to rotate the controller to win, and should aim for precisely that. The problem we’re analysing today is then: how do we make a decision on how much of a rotation to attempt if we’re the first player, and how much of an advantage does the game give the second player (at least as far as the final turn is concerned)?

Let’s make a couple of simplifying assumptions to this:

  • Let X_i be a continuous random variable over [0, \infty) and some is. The probability mass function of the X_i, f_{X_i}(x) are assumed independent, continuous and tending to zero as x tends to infinity. Furthermore, for a given value of x representing the number of degrees player i attempts to rotate the controller, we are successful iff X_i \leq x.
  • We assume scores are continuous (in the actual game, they’re only precise down to the degree).

Now, assuming we aim for a given rotation x, the probability of a win is then approximately f_{X_1}(x) \times (1 - f_{X_2}(x)), which we seek to maximise. Thus, for a simple example, if the X_i are exponentially distributed with parameters \lambda_1 and \lambda_2, we then seek to maximise the function

g(x) = (1 - e^{-\lambda_1x}) \times e^{-\lambda_2x}

This can be minimised, and yields a solution of x^* = \frac{1}{\lambda_1} \log \frac{\lambda_1 + \lambda_2}{\lambda_2}; this gives the first player a winning probability of

\left( \dfrac{\lambda_1 + \lambda_2}{\lambda_2} \right)^{-\frac{\lambda_2}{\lambda_1}} \left( \dfrac{\lambda_1}{\lambda_1 + \lambda_2} \right)

So if both players are equally skilled in terms of rotation ability (that is, \lambda_1 = \lambda_2) then the first player wins with probability of just 0.25. Furthermore, we can find out how much better player 1 needs to be for an even game (that is, the value of k for which \lambda_1 = k\lambda_2); we formulate

(k+1)^{-\frac{1}{k}} \left(\dfrac{k}{k+1}\right) = 0.5

which works out to about k = 3.4035. If this player went second, however, he would have an over 0.905 probability of winning!

The multiple trial case is interesting, especially because it seems like the problem does not demonstrate optimal substructure; that is, maximising the probability you win for a given round doesn’t necessarily mean that that’s the correct way to play if going for more rounds. For a simple (if highly contrived) example; let’s suppose we play two rounds. Player one can (roughly) make rotations up to 50 degrees with probability 1, 200 degrees with probability 0.3, and more than that with probability 0. Player 2 can make rotations up to 49 degrees with probability 1, 52 degrees with probability 0.6, and more than that with probability zero. To win one round, you should spin 50 degrees (win probability: 0.4); but to win two, if you spin 50 degrees twice, your opponent could spin 52 once and 49 once (leaving a win probability of 0.4); going for 200s and hoping for at least one success gives you a win probability of 0.51.

Iterative Dichotomiser (January Haskell Tests 2017)

I probably can’t really explain this much better than the source:

The January tests are on-line Haskell programming tests sat under examination conditions by first-year undergraduate students at  Imperial College at the end of a six-week introductory programming course.

Dr. Tony Field has been publishing them for quite a few years now (the linked page goes back to 2009). I still to some extent remember my first year Haskell courses, somewhat impressed by the rationale for choosing Haskell even though my understanding at the time was rather clouded. I do remember a specific instance where Tony polled the class on past programming experience, noting hands for C++ and Java (I raised my hand for both), and then tossing in Haskell (a few people; probably because Imperial did say to prepare to study Haskell beforehand!). Besides this, I think  having to worry less about persistent state (or race conditions, though I don’t think we covered concurrency at Imperial until second year) and being closer to the notion of mathematical functions, which students should already have been exposed to, would also have helped.

This year’s test (2017) covered decision trees, culminating in a question inviting candidates to implement the information gain version of ID3 when building a decision tree from a dataset. It wasn’t too difficult as a whole, as Tony acknowledged on his page; despite probably last having written Haskell about a year ago when I attempted the 2016 test, I finished comfortably in 2 hours and 12 minutes (the time limit is 3 hours). I think this test as a whole required some fairly careful work, but didn’t demand anything in terms of special insight even at the very end (as some past tests have done). The elegance of my answers would probably leave a fair bit to be desired, though; I found I was building recursive traversals of the given datatypes very frequently.

That said, I found the first part somewhat more difficult than in the past. Typically Part I was extremely straightforward (rather awkwardly, there used to be a question asking students to implement lookUp almost every year); not so much this time. In particular, there was a rather fiddly function to write that involved navigating some data structures and building a frequency table; the spec featured a lot of type definitions that reminded me a bit of some experiments with Object Calisthenics (in particular, the “wrap primitives and strings in classes” rule). That said, completing Part I alone would already have let you pass (with a 47; the pass mark is 40). I think the frequency table was harder than anything in Part II, actually, which had a few, fairly straightforward tree functions to write.

Moving on, part III effectively introduced students to the Strategy pattern (in terms of an attribute selector for deciding which attribute to split the dataset on). Apparently, it was possible to solve partitionData with a suitable one-liner, though I unfortunately didn’t come up with anything along those lines, and went with a rather “direct” approach of dividing the rows by the element and removing the relevant attributes. Part IV introduced the concepts of entropy and information gain, and thus invited students to implement ID3; given the title of the paper I wasn’t too surprised to see this at the end.

I found it fairly interesting to revisit Haskell, and it was nice to see that I was still able to work with the language after not touching it for a year or so. While it might be fairly unlikely that I would work with functional languages in professional terms, concepts and reasoning that are more apparent in functional languages do certainly apply even when I work in Java or C++, whether in the obvious sense (streams/map/filter etc.) or less so (inductive/algebraic datatypes).