Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mortality multiples? #59

Closed
nilshg opened this issue Jun 16, 2020 · 2 comments
Closed

Mortality multiples? #59

nilshg opened this issue Jun 16, 2020 · 2 comments

Comments

@nilshg
Copy link

nilshg commented Jun 16, 2020

Let me start off by saying really nice package, I'm not an actuary but this is really easy to work with!

Are there any thoughts as to the implementation of mortality multiples in the package?

A bit of background: I've got a set of insured lifes with current age and a given life expectancy. This life expectancy is lower than what would be implied by any table (which I do by finding the first survivorship < 0.5).

Googling around a bit it appears that people are actually just multiplying mortality by some constant and capping things at 1.0, which seems a little less than optimal?

Not sure whether this kind of functionality would be a good fit for this package, but thought I'd throw it out there.

As a side note:
One thing I've been doing (not sure how great an idea this is though) is to basically find the age at which life expectancy equals the given life expectancy, and then using the survival probabilities from that age onwards, so basically:

# Objective function
given_LE = [5.9]
obj(x; given_LE = given_LE) = abs(0.5 - survivorship(male_table.ultimate, x, x+given_LE[1], 
                                                    MortalityTables.Uniform()))

# Find age between 60 and 110 at which LE equals the given LE
implied_age = optimize(obj, 60.0, 110.0).minimizer
@alecloudenback
Copy link
Member

Yes, making multiplicative or additive adjustments is common, though it remains an unresolved issue (#27). It's very common to have that multiple vary by characteristics of the life under consideration (e.g. vary by underwriting risk class, size of life insurance policy, etc.) Because those characteristics are tied to objects/structs that I"m intending to build downstream packages for, e.g.:

  • LifeContingincies.jl a public package that I've been working on bringing up to compatibility with 0.9 of MortalityTables.jl as well as add a lot more functionality

  • The non-public and non-working LifeModeling.jl which would bring in real liability relationships: Lives, Policies, Coverages, Cessions, etc.

It's often by those Lives/Policies/etc that a mortality assumption varies so I haven't settled on what's the best place to put that code. It is probably worth putting some sort of basic adjuster function capability in this package though

Googling around a bit it appears that people are actually just multiplying mortality by some constant and capping things at 1.0, which seems a little less than optimal?

It is less than optimal :). My ultimate goal is to make working with real mortality tables easier and more functional (in the CS sense). There's a lot of practical issues with working with mortality tables and it's common to see simple but not-quite-theoretically justified modifications to base rates. I could expound here but let me try and just solve your immediate problem...

One of the design intentions of MortalityTables.jl is to make the rates really easy to work with. Once you have a vector of rates (ie an ulitmate table or a select table combined with an issue age), then you can modify the rates as you described:

# this multiplies the rates by 130% and caps them at 1.0
 survivorship(min.(m .* 1.3,1.0) ,0,1)

@alecloudenback
Copy link
Member

I'm not totally sure I follow what your specific broader goal is though... if you want you can hit me up on the #actuary channel on the Julia slack or DM me there and we can talk further. I'm going to mark this one closed in lieu of #27, I offered a scaling/capping solution, and we can continue discussion not related to the package functionality elsewhere.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants