CaseOutstanding()'s Approach 2 as Proposed by Friedland (2010)

The second issue in #159, the CaseOutstanding() method can only hand “Approach 1”, as demonstrated by Friedland, page 265 (or 271 by count).

We are missing Approach 2, as discussed and demonstrated on page 268 (or 274 by count).

[jbogaardt]

Looking at scikit-learn, such as this example, they consider hyperparameters as class parameters and fitted parameters as class attributes.

[kennethshsu]

The more I work on this, the more I feel like this method should be coded as a pattern instead of an IBNR model.

Let me try to summarize the two methods case outstanding methods.

The first CaseOutstanding() method takes in two triangles, paid and reported, and goes through some algorithms to calculate a case to prior case LDFs, paid to prior case LDFs, and it develop the case triangle as well as the adjusted paid triangle to get to ultimates. This model then then returns an implied LDF for paid, which needs to be used in conjunction of the Chainladder() method to get to the ultimate.

The second case outstanding method takes in two arrays of patterns (paid and reported) and then return a third pattern, which needs to be used in conjunction with the Chainladder() model to get to the ultimate.

If the first model is implemented as a pattern adjustment, why shouldn’t the second? In fact, I think the first method should be implemented as an IBNR model, and the second should be implemented as a pattern method.

There is a technical problem though. If the second method is implemented as a pattern, the return pattern used with chainladder will estimate everything correctly except the first origin period. This is because I believe chainladder assumes the last LDF to ultimate to be 1.000; if it is not 1.000, a TailConstant() is expected to be used instead of LDF/CDF to be used?