Magic Formulas and Raspberry Pis

Is investing like computer programming? The gut reaction would be to say “no”. Investing is a very “soft” skill, whereas programming is a “hard” skill, almost as uncompromising as mathematics. There are, however, some interesting points of commonality that I’d like to explore.

In my previous post, I talked about different programming languages, and how I used the Python profiler effectively to reduce execution time on my RPi (Raspberry Pi). The secret of code optimising is to try to get the biggest hit first. It borrows from the 80/20 rule.

In case you have no idea what I’m talking about, a “profiler” is a piece of software that breaks down a running application into the routines called, the number of times they’re called, and the total time they’re called. If a program is running slowly, a programmer might profile his code and look at the output to see where the bottlenecks are. By concentrating on the bottlenecks, and changing his algorithms, the programmer should be able to speed up his code. Ultimately you can’t reduce execution time to 0, and there are some bottlenecks you can’t fix. Typical cases would involve database access, or access to network resources. These things generally take as long as they take, and no amount of tweaking will shorten execution time.

Awhile ago, I had commented that I thought that the Magic Formula was quite a “mixed bag”, containing Chinese frauds, stodgy staples, cyclicals at their peak, and so on.

It struck me that an application profile was a lot like a portfolio: a long list of entries with some performance stats. One big difference, of course, is that an application is a lot more deterministic than a portfolio. An application which has a bottleneck in one place one year will generally have the same bottleneck in that place the next year, all other things being equal. The price of Vodafone, on the other hand, will vary from year to year, and the amount that it varies will depend, at least in part, on its price. Share prices are adaptive, whereas applications that aren’t altered tend to have more stability in their performance.

Things became interesting when, yesterday, I watched an interesting YouTube video: ‘Velocity 2012: John Rauser, “Investigating
Anomalies”‘ (http://youtu.be/-3dw09N5_Aw). It was about how programmers could identify performance issues in web applications. Amongst his first words were: “If all you do every day is look at summary statistics, in particular time series plots … then you are missing out, because you really have no idea how your system functions. That summary statistic is washing away a huge amount of detail”

I suggest you watch the whole of the video, wearing your investor hat.

Sticking to it from a computing angle, if you plot some function, like system load, over time, what you find is something generally quite flat, with some ups and downs. This doesn’t tell you very much. It’s only by “digging down” can you actually find out something useful. Two suggestions he came up with is drawing histograms, or, even better, reading log files. As an aside, it can be quite fascinating to log at server log files, as you realise that there are many attempted attacks on your system. You can see them seeing if there is common
administration software, misconfigured, so that an attacker can obtain a toehold on the system.

Instead of drawing a time plot, it is more instructive to draw a histogram of the time it takes a web page to be served. It is often more revealing. What you’ll probably see is a highly skewed
distribution, non symmetrical like the normal distribution at all, with very long tails. You learn a lot by looking at the edges of the distribution – i.e. not at the central core. Some requests take almost no time at all. “Great”, you think, “that’s really good”; until you find that they were simply requests for invalid pages. Well, they shouldn’t take long to serve at all. The other extreme can be much more informative. The presenter found, for example, that some pages were rendered using javascript and loaded 47 images from other domains, and took 20 s before the page even began to render in the browser. This is highly illuminating, and suggests areas where optimisation is likely to be profitable.

The presenter suggested that a strategy that was likely to be better than just plotting a time series of the average length of time it took for a page to be served was to look at a percentile in the high 90’s, for example. When he did that, he found that page serves proceeded as normal for a time, but then spiked upwards. It corresponded to a change in infrastructure. Aha! That’s obviously a fruitful ground for investigation.

I think that this has interesting parallels to investing. We may know that Greenblatt’s Magic Formula generally does well, whilst often underperforming, but we don’t know why. It reminded me of a discussion by Fundoo Professor. When you look at companies, some will be disasterous, some will be mediocre, and some will be superb. Three buckets. Your job is to avoid the first bucket, ignore the second bucket, and stick all your money into the third bucket.

Obviously, you will still make mistakes, and make many
misclassifications, or simply run into bad luck. But that’s the goal.

With this in mind, I might try to perform an investigation of the performances of the Stockopedia’s Magic Formula screen, to see if there’s any information that can be gleaned. It takes time to allow performances to out, though, so I don’t expect any firm conclusions quickly.

But stay tuned.

Advertisements

About mcturra2000

Computer programmer living in Scotland.
This entry was posted in Computers, Magic Formula Investing. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s