R Souls - 28April2006


Proposed agenda

 

1. Structure of Reserving Package

 

As discussed at Friday’s meeting, here is a quick description of the structures and functions that I've created so far. If we can merge this with Markus's existing package and agree on a common format, then it should be easier to cooperate on further development.

 

The reason I wanted to use an array to perform some of the calculations is that I’ve found them much faster for performing large numbers of calculations. This is useful for Bootstrapping – as this old prototype shows, 10,000 simulations can be run in approximately 20 seconds on an old laptop.

 

Based on this, I’ve started with the bare bones of relevant classes for a reserving package. I’ve broken the code into different files:

 

 

The files can be found in this zip. I know it’s a little frustrating that you need to run different files, but this is easy in TinnR and I find it useful for organizing large projects. Then if someone writes a new class (for example MunichReCL), they can just add another file to the collection, without adjusting previous ones (unless adding code to be shared by other classes).

 

A more detailed discussion follows. If you disagree with some of the conventions used, then please comment.

 

There are two triangle classes used so far: “ArrayTriangle” and “LongTriangle”. Whilst they need not strictly be triangles, the term triangle is used universally for claims data, so I’d suggest keeping it. In line with the naming convention for classes, the names above are mixed case nouns, starting with a capital. We may wish to rename “TriangleArray” and “TriangleLong” – what do you think?

Each class has a constructor function, with the same name as the class. This creates an instance of that class.

Each class has a coercion function, which is the class name with a “as.” prefix (i.e. as.ArrayTriangle). This converts appropriate data into that class (i.e. ArrayTriangle to LongTriangle).

Each class has a print and plot method for use with the generic functions.

Other functions are used for reserving, in particular:

 

  • makeCumulative (should this be getCumulative)
  • makeIncremental (should this be getIncremental)
  • getLatest

 

In line with the naming convention, these start with a verb and are mixed case, starting with lowercase.

 

The above are generic functions. Specific methods are created for each of ArrayTriangle and LongTriangle.

 

A method has the name of the generic function, followed by a period and the name of the class to which that method applies.

Internal functions (i.e. those not intended for the user of the package) are preceded with a period. (Note: I have also used the same convention for variables within a function).

 

For example, converting from an array to a long format is something we may wish to use in other classes (e.g. for development factors). Reshape is not particularly fast, therefore “.formatLong” is an internal function to provide this utility.

I wanted to have a class of development factors, but I’m not sure what this class should look like or if we want more than one class.

 

Currently I have a single class created from a Triangle and some other options. The individual development factors are stored. An average is calculated (currently only one method implemented, no tail factor yet). Ultimate DFs are also produced.

I wanted to have a class for each result type e.g. ChainLadder, BF, MunichReCL, etc.

 

Perhaps these result classes should have common features (e.g. data = original triangle; ult = projected ultimates; exp = expected claims development; etc.)? Then we could have standard methods such as calculating residuals or applying a bootstrap methodology.

I’ve made a start on the ChainLadder class, but not got very far. It takes a Triangle and a chosen set of development factors and produces reserves and some ultimates.