Friedland Recreation Chapter 8

[kennethshsu]

Summary of Changes

• Chapter 8 in Friedland in ipynb format
• Added Population to friedland_gl_self_insurer
• Added Earned Premium to friedland_us_auto_chg_prod_mix
• Added Earned Premium to friedland_us_auto_steady_state
• Corrected a AY error in friedland_us_auto_steady_state.csv
• Further addressed a problem in the year end issue that was incorrectly closed in friedland_gl_self_insurer is showing that has valuation of 01/31/2008 instead of 12/31/2008 #919

Related GitHub Issue(s)

#588
#919

Additional Context for Reviewers

Preview here

• I passed tests locally for both code (uv run pytest) and documentation changes (uv run jb build docs --builder=custom --custom-builder=doctest)

---

Note

Medium Risk
The development_format == "%Y-12-31" branch changes how development axes and lags are built for any triangle using that format, which can shift downstream reserving results; sample CSV edits are documentation/test data only.

Overview
Adds Friedland Chapter 8 to the docs TOC (friedland/chapter_8.ipynb) and extends bundled Friedland sample data so Chapter 8 examples can use exposure-style measures.

Triangle construction: When development_format is "%Y-12-31", development dates are normalized to year-end timestamps via to_period("Y").to_timestamp(how="e") in _set_development, addressing the year-end valuation bug from #919 for samples like friedland_gl_self_insurer.

Sample updates: friedland_gl_self_insurer gains a Population column (manifest + CSV); friedland_us_auto_chg_prod_mix and friedland_us_auto_steady_state gain Earned Premium; friedland_us_auto_steady_state.csv also corrects accident-year row errors.

^{Reviewed by Cursor Bugbot for commit 0c07941. Bugbot is set up for automated code reviews on this repo. Configure here.}

[kennethshsu]

Thanks so much for the feedback!

• chapter 9 is in this branch. can you please delete? otherwise we'll have to wait for chapter 9 to be approved before approving and merging this PR.

I pulled again from main now that chapter 9 is in, there should be no diffs now.

• we just merged a consolidated uspp sample dataset in Add merged Friedland USPP sample dataset #1116. i thought it was a more elegant solution than having four very similar, very separate datasets. it's also useful for the package to have another reasonably sized multi-triangle (clrd gets unwiedy at times). would you mind switching over to using that consolidated dataset?

Yes, and I like this implementation better too.

• having asserts in every single cell is pretty distracting. i would recommend that you move all asserts to a single cell at the end of each page

Good call, revised.

• we probably don't need asserts on every single column. for example, for exhibit 1 sheet 1, just column 12 is plenty (all preceding columns have to be correct)

Ehh, I think I am going to leave these in now, it will be easier to trace back if something is failing. Let me know how strong your opinion is lol...

• some of these asserts require visual inspection, like Exhibit III Sheet 1, column 11. we shouldn't have both sides be hardcoded.

Good call, will remove those. I tried to do remove as many as I could but missed some.

• p141 is only printing a few columns

Reprinted.

• For Exhibit III Sheet 2, can you loop to create a bunch of Triangle or Trend objects? Using pandas to do any heavy lifting is kinda like admitting defeat on package completeness

Hmm I just did it using the Trend and rebasing inside Triangle, I don't really like it. Do you have a better solution here? I think there's opportunity to improve this in TrendConstant by just adding in a valuation_date argument or something like that.

• Exhibit III Sheet 3 rtol=0.5 means +/- 50%

Oh yes, I'll use atol instead. They are at most 3 units ($).

• ultimately, i think the per-column approach is not very reader-friendly. i know you have some aversion to caring too much about formatting. take a look at something i'm trying for chapter 11. i front-load all the analysis code at the start of each exhibit, to illustrate what a realistic production workflow might look like. then if reader don't care about each individual sheet, they don't have to read through each sheet. i think you can do the same, i.e. distill the full analysis to the first cell of each sheet and only print out the key result (the last column in most instances). we can get another collaborator to construct full frames from the columns

I can see the benefit of both, though I still feel like that's an overkill as the key of this recreation is to show how to perform calculations/analysis using the package, not so much exhibit building. I do think once all the chapter are in, we need to sync up to make sure they all look the same relatively.

[henrydingliu]

though I still feel like that's an overkill as the key of this recreation is to show how to perform calculations/analysis using the package

we seem to be getting into another one of those convos where you say one thing but implement something to the exact opposite. when i read this notebook, i don't get the sense that 'perform calculations/analysis' is in the top 3 of priorities. one of my monitors is set up vertically for reading memos. here is a screenshot of what that looks like

by raw screen estate, the analysis is not even 10%. it's print statements, hardcoded dev patterns, and columns and columns of numbers in single file. by contrast, here is the current state of chapter 11 that i tried to suggest as an alternative

don't you think this is actually much more aligned with 'the key of this recreation is to show how to perform calculations/analysis using the package'?

[henrydingliu]

Ehh, I think I am going to leave these in now, it will be easier to trace back if something is failing. Let me know how strong your opinion is lol...

if someone else submitted this and you are reviewing, you really wouldn't think this is overkill?

[kennethshsu]

That looked horrible and I fixed it. I copied the results from the actual run and forgot to replace with the values from the text.

by raw screen estate, the analysis is not even 10%. it's print statements, hardcoded dev patterns, and columns and columns of numbers in single file. by contrast, here is the current state of chapter 11 that i tried to suggest as an alternative

I don't know that this is a fair comment lol, you are looking at columns that are just data, of course it's not "useful".

When I was constructing this workbook, I was thinking what would be most useful to a reader if they wanted to recreate the examples in the text, and do only that. The chapter 11 stuff is doing so much more than teaching users how to use the package, it's actually doing reconstruction with exhibits, and imo, is too much. It's actually harder for the users to figure out exactly which line of code will recreate the numbers. I'm not saying we shouldn't go there, but I don't think that is a priority now. If we think this is the MVP and are all aligned, than I will do that, but we should all come to an agreement here.

Anyways, we have a few chapters in now, and they all look widely different. We will need to decide how to standardize them.

Please take another look and see if I missed anything...

[henrydingliu]

The chapter 11 stuff is doing so much more than teaching users how to use the package, it's actually doing reconstruction with exhibits

but it is not. please take a moment and read the cell under "Exhibit 1 Analysis". it's not printing anything. it's not doing any pandas manipulation. it's using chainladder API and only chainladder API.

When I was constructing this workbook, I was thinking what would be most useful to a reader if they wanted to recreate the examples in the text, and do only that.

That's a worthy approach. but this notebook is not actually accomplishing that. right now it's very hard for a reader to follow. when you read this notebook yourself, i'm sure you are scrolling straight past the print statements and focusing on the chainladder bits. But a new user does not have that visual filter baked in.

If we think this is the MVP and are all aligned, than I will do that, but we should all come to an agreement here.

I'm not saying that well-formatted exhibits is the MVP. i'm saying that (1) printing individual columns is distracting; (2) if you dont want to print full exhibits, then do a version of what I'm doing in chapter 11, i.e. do all the analysis, and just print out the final ultimate.

Anyways, we have a few chapters in now, and they all look widely different. We will need to decide how to standardize them.

I think having different coding styles are fine. it showcases that this is a community project, and that all coding styles are welcome. right now this chapter 8 is the only one that looks wildly different, because of the individual columns.