| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Stop wasting time looking for files and revisions. Connect your Gmail, DriveDropbox, and Slack accounts and in less than 2 minutes, Dokkio will automatically organize all your file attachments. Learn more and claim your free account.

View
 

R Souls - 28April2006

Page history last edited by PBworks 14 years, 7 months ago

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:

 

  • One for each class.
  • A General Functions file for internal utility functions appropriate to more than one class.
  • A Reserving Functions file for both internal and external reserving functions. Contains some examples at the bottom.

 

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.

Comments (2)

Anonymous said

at 10:23 am on May 2, 2006

Nigel, this is excellent. Taking your questions in turn: "Triangle" - yes I agree we should call them triangles even if they arent. Rename "TriangleLong" rather than "LongTriangle" - dont feel too strongly, perhaps the former gets the key concept accross first. I personally prefer "makeCumulative" to "get" - but happy either way. Thanks for using the suggested coding conventions - it will make the output look coherant. Output classes to have common features (data, ult, exp) - very good idea - then, as you suggest, we can build generic graphical functions.

Anonymous said

at 10:32 am on May 2, 2006

Nigel, I'd agree with the use of 'Triangle' for claims data even though the claims data may not strictly be presented in a triangle format. A number of other reserving packages I've used ask the user to upload/create/select a 'Triangle' even if the data is not exactly presented in that shape.

You don't have permission to comment on this page.