Around this time last year, I was frantically studying for my last actuarial exam. With the future of my career on the line, I decided that in the three to four months leading up to my exam, I would drop everything – that is, exercise, hobbies, social activities, and academic interests – to study for this exam. This was an unprecedented move on my end, as I had, up to that point in my career, maintained my outside interests while simultaneously preparing for my exams. However, I believed that since this was my last exam, and with no fall exam on the horizon, that I would be able to catch up on these things later.

The good news is that I passed, after having put in about 6 hours of study per day over the course of 100 days. The bad news is that I had put the rest of my life on hold, including my (hopefully) lifelong experiment with spaced repetition, using Anki. For those of you who are new to this, spaced repetition is an optimized technique for memory retention – you can read more about it here. Halting progress on notecard reviews is problematic, for a couple of reasons:

1. There is no way to pause Anki. Anki will keep scheduling cards even when you aren’t reviewing them, so it can be very difficult to catch up on your reviews, even if you’ve missed just a few days.
2. Anki schedules cards shortly before you’re about to forget them, which is the best time to review the cards for maximum retention. Because of this, you are likely to forget many of the cards that are on backlog.

Thus, despite the relief I felt over never having to take an actuarial exam ever again, I faced the daunting task of getting back to normal with my Anki reviews. Since I use Anki as a permanent memory bank of sorts, I never delete any of the cards I add – that means I cumulatively review everything I have ever added to my deck over the last five years. This makes the issues I outlined above particularly problematic.

Upon waking up the day after my exam, I discovered that I had over 12,000 cards to review, a backlog which had accumulated over the past three months:

Although I was eager to resume my studies, this backlog would be something I would have to deal with first, since it would be difficult for me to review new material without taking care of the old material first. I assume that most people would simply nuke their collection and start over, but since I had been using Anki for several years, I was confident I’d be able to get through this without having to delete any of my cards.

The first step was to pick the number of reviews I would have to do per day. The tricky part was that if I did too few, the backlog would continue to grow. However, there was no way for me to get through all 12,000 cards within a single day. I settled on starting with 500 reviews per day – a nice, round number that I could easily increase if I noticed I was falling behind.

As the days went by, I recorded the number of reviews I had remaining at the start of each day in a file called cardsleft.csv. The graph below shows that it took about three months to reach a level of about 1,000 cards per day, which was the point at which I declared the backlog to be cleared:

I worked my way through my collection one deck at a time, starting with programming languages, since I wanted to start studying a new JavaScript book as soon as possible. Once that deck was cleared, I started adding new cards pertaining to JavaScript, while simultaneously clearing the backlog in the remaining decks.

That’s all I had to do, and all it took was a bit of consistency and perseverance over three months. Now things are back to normal – I normally review 800 – 1200 cards per day.

Other Spaced Repetition Updates

It’s been a little more than a year since I last wrote about spaced repetition. I’m happy to say that my experiment is still going strong, and my personal goal of never deleting any cards has not placed an undue burden on my livelihood or on my ability to study new material. Since Anki stores its information in a SQLite database, you can directly connect to it with R to analyze its contents.

For the most part, the deck composition by subject has remained similar, but the computer science portion has increased due to my focus on databases, JavaScript, Git, and R:

In the time that has passed, my deck as grown from about 40,000 cards to 50,000 cards:

And, thankfully, the proportion of my time preparing for actuarial exams has dropped to near zero:

A triangle is a data structure commonly used by actuaries to estimate reserves for insurance companies. Without going into too much detail, a reserve is money that an insurance company sets aside to pay claims on a book of policies. The reason why reserves must be estimated is due to the uncertain nature of the business – that is, for every policy sold, it is unknown at the time of sale whether or not the insured will suffer a claim over the policy period, nor is it known with certainty how many claims the insured will file, or how much the company will have to pay in order to settle those claims. Yet, the insurance company still needs to have funds available to satisfy its contractual obligations – hence, the need for actuaries.

Triangles are popular amongst actuaries because they provide a compact summarization of claims transactions, and are an elegant visual representation of claims development. They are furthermore amenable to several algorithms that are used to estimate the reserves, such as chain ladder, Bornhuetter-Ferguson, and ODP Bootstrap.

I had originally set out to do something more ambitious for today – that is, to automate the production of browser-based triangles via JavaScript, but I’m not quite there yet with my studies in the language, and moreover simply setting up pieces of the frontend involved enough work and learning to merit its own post.

Today, I’ll go over the visual presentation of actuarial triangles in HTML, while later posts will cover automating their production via JavaScript, JSON, and backend calculations.

Below, you’ll find a table of 15 claims, taken from Friedland’s text on claims reserving. The Claim ID is simply a value to identify a particular claim. The other two columns have the following definitions:

• Accident Date

The accident date is the date on which the claim occurs. For example, if you were driving on January 5 and had an accident during that trip, then January 5 would be the accident date.

• Report Date

The report date is the date on which the claim is reported to the insurer. If you were driving around on January 5 and had an accident during that trip, but didn’t notify the insurance company until February 1, then February 1 would be the report date.

You may be wondering why actuaries would care about the distinction. In the table below, you see that at worst, claims are reported only a few months after they occur. In certain lines of business, however, claims can be reported even many years after they occur. One example would be asbestos claims, in which cancer may not develop until many years after exposure to the substance. Another would be roof damage resulting from storms, in which the homeowners may not know that their roofs are damaged until the next time they climb up to go see, which may happen some time after the storm in question.

There really isn’t much to it, but I did learn a few things here. In particular, the HTML attribute colspan was used on the top row header to merge the top few cells together. Furthermore, I altered a ruleset to this site’s CSS, which centered and middle-aligned the text within the table:

While the above table is straightforward to understand, there isn’t much that you can do with it. First, there aren’t any claim dollars attached to those claims, so we won’t be able to perform any kind of financial projections if there aren’t any historical transactions. Second, even after getting the transaction data, the presentation can get messy because the order in which transactions occur don’t always coincide with the order in which claims occur or are reported.

We see that this is the case in the table below, which shows the historical transactions for this group of claims. The first payment for claim 9 occurs before the first payment for claim 4, even though claim 4 occurred first.

A more visually appealing representation orders the claims chronologically by date of occurrence, while ordering the transactions horizontally by date of payment.

I’ve picked up a few pieces of syntax here, as not only have I made use of the colspan attribute, but also the rowspan attribute, allowing the first three subheadings of the table to occupy two rows each. Furthermore, I’ve added horizontal lines to visually separate the claims by accident year, by adding a new ruleset to the site’s CSS:

Finally, although the above table provides a better description of the book of business, it is not compact, and nor is it in a form that is amenable to reserving calculations. Below is a table that aggregates the transactions by accident year, on an incremental paid basis. Below that, is a similar table, but stated on a cumulative paid basis.

While I’ve got the visual representation of what I want to achieve here, there’s still quite a bit of work to do. As you can see here, there’s a lot of repetition, and hardcoded redundant values in the code. Indeed, I caught several errors prior to publishing this post. Next, I’ll aim to streamline the production of these tables via JavaScript with the following tasks:

1. Store claims data as a JSON object

Repetition increases the chance for error – for example, you can see that I’ve repeated several bits of data such as the accident date for many of these claims. It’s better to store them in one location, perhaps as a JSON object.

2. Write a JavaScript function to read the JSON, construct the tables, and populate the tables

The tables above took a lot of copying and pasting of HTML tags. It would be more efficient, and less error-prone, if I automated the construction of these tables with a function.

I’ve got a few side projects going on, one of which involves creating a web application for some of the actuarial libraries I’m developing. Since I have a bad habit of quitting projects shortly after I’ve announced them to the public, I’m going to wait until I’ve made some progress on it. In the meantime, I’d like to talk about some of the tools that I’ve had to learn in order to get this done – one of which is JavaScript.

I came across JavaScript a many years ago, back when D3.js came out. Upon seeing D3 for the first time, I was immediately amazed at how beautiful the examples were – so much so, that I decided to learn it myself. However, I found the learning curve to be steep, and it soon became apparent to me that I was going to have to learn a lot if I wanted to get good at it. This meant that I would have to take a step back and learn JavaScript, the language underlying D3. Today, I won’t be talking about D3, but I will go over some of the JavaScript that I’ve learned so far, particularly the flotr2 library.

While the charts that I’m showing you today are simple, constructing them is deceptively challenging. The reason why is that producing high-quality graphics (and later, high-quality dynamic graphics) on the Web requires a large body of prerequisite knowledge, including but not limited to:

• HTML

HTML, or HyperText Markup Language, is a markup language that dictates the logical structure of a web page. The structural components that you see on this web page, such as paragraphs, titles, headers, and links, are dictated by HTML tags.

• CSS

CSS, or Cascading Style Sheets, is a style sheet language that dictates the aesthetic layout of a web page. The stylistic features of this web page, such as fonts, colors, margins, etc., are dictated by CSS rule sets.

• JavaScript

JavaScript is a programming language used to create dynamic web pages that respond to user interaction. You may have seen some websites load different charts depending on what the user does. There’s a high chance they were driven by JavaScript.

• Artistic Ability

Many books have been written on the three subjects above. I have encountered many programmers who have spent hours upon hours reading as many books on HTML, CSS, and JavaScript, only to end up producing horrible-looking charts when they try using something like D3,js. Why do their charts look so terrible, when they possess all of the prerequisite technical knowledge to produce them? One reason why, is that they lack artistic ability. Not only would you need to know three languages, but you also have to be skillful in graphic design. The ability to choose an appropriate color palette, careful selection of margins, and subtle placement of graph elements are required.

• Domain Knowledge

Lastly, if you’re going to present something, you really need to know what you’re talking about. I have spent many years trying to become a subject matter expert in actuarial science. However, this post isn’t about that, but moreso about visual presentation. But still, you should have some substance to your methods, if you want to be able to back up your claims.

Early in my career, I recall an executive telling me that there are a lot of smart people out there with brilliant ideas, yet they fail because they can’t communicate those ideas clearly and concisely, nor can they persuade anyone.

Humans can be irrational creatures, and aren’t always persuaded by facts. I’ve taken this advice very seriously, and these days my strategy is to use good visual and oral presentation skills to persuade people – while simultaneously carrying out the technical work behind the scenes to a high level of standard, so that I can back my claims up if examined thoroughly.

Now, you might ask, why should I bother learning all of this stuff when I could have just mocked up a bar chart in PowerPoint, and copy-and-pasted it here? There are many good reasons – first, it would make for a very boring blog post, and second, I have greater ambitions for using these technologies in the development of web applications, and not just a one-off blog post. In a web application, the data underlying the charts are stored in a backend database, and explicitly defining the data transfer routines and parameters of those charts via code enables the automatic loading and rendering of charts – when you have thousands of users, the technical way becomes much more productive. Third, reproducible research is a core tenet of the scientific method. Good code can be self-documenting, and being able to reproduce experiments via the execution of well-maintained code will help you justify and defend whatever it is that you’re trying to prove.

flotr2
flotr2 is a JavaScript library that produces simple charts. I plan to transition to D3 later, but I think it’s a good tool for people who are new to JavaScript. Sadly, the two charts that you see below are the culmination of over 500 pages of reading. 400 of those were on HTML and CSS, which I read way back to produce this website that you see here. The other 100 come from some pieces of JavaScript that I read in a web application development book, and from another book that I’m reading on data visualization with JavaScript.

CSS and JavaScript
The examples below depend on two scripts. One is the same CSS script underlying the webpage, and the other is the flotr2 library, stored in a JavaScript file. I’ve placed both these files on my server, and I’ve linked to them in my web page:

The following chart, is generated by the script below it. The data are arbitrary, but you can see here that the parameters corresponding to what you see in the cart, are specified in the code (expense data, title, colors, etc.).

Now we can change some things up. Let’s say instead of expenses, we want losses. I’ll do that by changing up the title, variable names, color, and data points: