Potential Enhancements

[tom-farmer]

Here are a few enhancements that I see being useful.

• Add functionality for a global start/end time in the addExposures function call. This is easier than filtering the final dataset, which could get massive, especially if you're talking about monthly exposures on hundreds of thousands of old policies with older issue dates. Changing the start_int and end_int in the input dataset doesn't seem to be an option as it would result in incorrect durations.
• Add functionality to carry policy level attributes through the addExposures function. Today if you call addExposures(records) the 'gender' variable is dropped. I know it's possible right now to run addExposures and then left join the attributes from the original dataset back on, but this is an extra step that we can eliminate from users work flows.

[tom-farmer]

Upon closer inspection it looks like you already have the first bullet covered, but I still think the second bullet could add value. If I get some time, I may take a stab at.

[tom-farmer]

@ActuarialAnalyst Dumb question here: if I want to add in this functionality to this package myself, is the easiest way to have my own fork of it on github, then merge request my code from there, or to have a branch in your repo and then push to that and merge from there? Does it matter? Never collaborated in GitHub before, so I'm a bit new!

[MatthewCaseres]

I am honestly sort of new to this as well! I haven't collaborated on any software before. This article seems relevant https://help.github.com/en/github/getting-started-with-github/fork-a-repo. I think this is the first option you describe (fork then merge).

Feel free to keep me informed on what features you think would be interesting and any challenges or questions you have.

[MatthewCaseres]

Oh wow, I actually hadn't noticed any of this thread before today. I'm sorry I didn't get back to you. The premium pattern analysis also has a lot of potential for improvements. I wrote an article on this package for the last "Modeling Platform" newsletter. Maybe a couple of fixes would be worth an article detailing progress.

Historically I have taken the perspective that users should be good at R and I have neglected certain (possibly obvious) improvements. Thanks for looking around.

[MatthewCaseres]

I'm imagining that addExposures gets an additional optional argument where you place in a vector of strings that represent column names. I won't mess with addExposures for a while. Your interest is making me want to do some work. If I mess around it will be in premium patterns.

I feel like the best possible improvement would be ditching the "users need to have their columns named in a certain way". This is probably best done through the "curly-curly" syntax or by moving to Data.Table. Writing dplyr functions gets kind of weird.

[tom-farmer]

Great thoughts here, that article is really helpful. I will set my fork up to sync to yours so I can stay up to date. Once I have some code I want to push I can open a merge request and we can hash out the details of the code there.

I was thinking slightly differently for the addExposures function but that vector of strings could work as well. I'll work something up and then tag you in an issue to see what you think.

Overall I hope that people are good in R but my experience so far has been that actuaries are pretty new to R and open source software in general. I think making it really easy with good documentation, good vignettes, and easy to use code will help folks along the path! (All of which you already have, I think!)