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
Changes core triangle date initialization logic used by load_sample and user triangles; scope is narrow (one format string) but affects development lag axes.

Overview
Adds Friedland Chapter 8 to the Jupyter Book TOC (friedland/chapter_8.ipynb) for the recreation series tied to issue #588.

Triangle development dates: When development_format is %Y-12-31, development is now re-normalized to calendar year-end via to_period("Y") and to_timestamp(how="e") in _set_development, addressing year-end parsing issues from #919.

Bundled Friedland samples: Manifest and CSVs gain extra measures—Population on friedland_gl_self_insurer (with existing %Y-12-31 format)—and Earned Premium on friedland_us_auto_chg_prod_mix and friedland_us_auto_steady_state, with steady-state claim rows corrected for accident-year alignment.

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

[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.

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 577a718. Configure here.}

[kennethshsu]

Ok. I reworked the exhibits and now they look much more like Chapter 7's now. Please take a look and let me know of any other feedback.

New doc

[henrydingliu]

as_series is called a whopping 48 times. we should add it as a util function into the package, or maybe change the behavior of to_frame. alternatively, give cl.model_diagnostics a chance

• page 140

exhibit_i_s1["CDF Reported (4)"] = origin_cdf(auto_bi["Reported Claims"], reported_pattern).values
exhibit_i_s1["CDF Paid (5)"] = origin_cdf(auto_bi["Paid Claims"], paid_pattern).values

i've been harping on this to the other collaborators, so i gotta be fair here and give you the same feedback. we should use the chainladder API whenever we can. so either reported_bi.ldf_, or cl.model_diagonstics(cl.Chainladder().fit(reported_bi)).