juliaactuary / lifecontingencies.jl Goto Github PK

There's a lot of very short characters exported by the module, which pollutes the user's namespace. Some solutions:

1. Don't export anything and require explicit import
2. alias some of the basic functions e.g. insurance for A and export the aliases
3. Keep as is

I'm leaning towards option 2 as the best use case for most people.

Such as those in https://github.com/JuliaActuary/LifeContingencies.jl/blob/master/test/runtests.jl

Pull interest rate functionality out of this package and utilize Yields.jl

#14 added the structure and basic mortality rate calcs, but expand to make the insurance calcs work

It's convenient, but not particularly performant.

Avoid defining names that conflict between packages, such as cashflows and timepoints. Currently Yields.jl and LifeContingencies.jl have these defined. And may become even more pertinent if assets are added in a separate package, as hinted at in #37

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

Hello guys,
Nice project, here!
However, it'd be nice if we had fractional ages allowance by default.
For example, allowing fractional ages directly when instanciating SingleLife
objects knowing the fractional_assump... this implies changing
the way a couple of methods are implemented but it's relatively a light!

Thanks.

In trying to extend the built-in functions to include immediate annuities, I have encountered an area that highlights an ill-defined aspect of the API:

Currently, ä(ins,5) (ä(ins,to_time)) refers to the annuity-due payments that occur between times [0,5), so that includes five payments.

In extending this to an annuity certain, a(ins,5) referring to the interval [0,5) would only receive four payments at times 1,2,3,4.

This is inconsistent with how the literature portrays a(ins,5) as the 5 refers not to time but number of payments.

Question is: change the API to be consistent with the literature?

• Immediate
• Certain
• Life + Certain

Trying to create the plots toward the bottom of the README produces the following error:

julia> for (i, t) in enumerate(tables)
           plot!(plt, issue_ages, whole_life_costs[i], label="$(t.d.name)")
       end
ERROR: type UltimateTable has no field d
Stacktrace:
 [1] getproperty(x::MortalityTables.UltimateTable{OffsetArrays.OffsetVector{Float64, Vector{Float64}}}, f::Symbol)
   @ Base ./Base.jl:42
 [2] top-level scope
   @ ./REPL[362]:2

I tried looking for a way to extract a table name (or other field) from a table object, but it was not obvious or intuitive. fieldnames was not helpful here. Needless to say, this underscores two issues:

1. the example in the documentation is currently not reproducible
2. it's not clear (or easy) how to extract fields and/or metadata from table objects

Refactor to make the types of insurances, well, types instead of functions. Example:

Current:

annuity_due(ins) currently calculates the present value of an annuity due.

Alternative:

a = AnnuityDue(ins) constructs an object, for which the following functions would operate:

• cashflows(a) would produce the vector of cashflows
• survival(a) would produce the survivorship vector
• timepoints(a) would produce the timepoints associated with the cashflows
• discount(a) would produce the discount vector
• Replicating the current functionality, present_value(a) would extend ActuaryUtilities.present_value and calculate the APV via the present_value(ins.interest,cashflows(a) .* survival(a),timepoints(a))
  • Could specialize this function to the existing calculation if the duplication causes material speed slowdown

Advantages of this:

• allows for breaking the constituent pieces apart
  • e.g. facilitates calculating the liability duration via the cashflow analysis methods in ActuaryUtilities
• the insurances are now combine-able:
  • e.g. Insurance(ins) - AnnuityDue(ins) would create a new instance of a ContingencyCombination where it combines the insurance benefit less the annuity payments, resulting in the net product cashflow.

Disadvantages:

• potentially duplicating calculations? E.g. the timepoints may need to be calculated three times for an APV instead of just once.

v(int,1:10) returning the discount vector for times 1:10 seems a lot more useful than returning the 1-year discount rate at each of those time points. Makes #20 easier to refactor

E.g. lapses, or different types of claims

e.g.:

v(lc,5) instead of v(lc.int,5)

Since, for example, Ax has x as an argument to the function, should the functions really be defined as A(lc,x) instead of the current Ax(lc,x)?

For some functions like reserve which is commonly denoted tVx in the literature, it creates odd function calls:

• Current: tVx(lc,x,t)
• Possible shortform alternative: V(lc,x,t)
• Possible longform alternative: net_premium_reserve(lc,x,t)

If switching to the less redundant functions, then namespace becomes an issue. For example, if there's a bunch of one letter variables (v,a,A,V, etc) then how to deal with this?

Possible solution:

• Define longform names that do get exported, such as annual_net_premium instead of Px
• Define the shortform (e.g. P) but don't export, and let the user pick if they want to bring the shortform versions into scope

timholy.github.io/SnoopCompile.jl/dev/snoop_pc

#19 did this for interest rates... but why not everything?

life = SingleLife(                 # The life underlying the risk
    mort = vbt2001.select[age],    # -- Mortality rates
    issue_age = 30                 # -- Issue Age
)

yield = Yields.Constant(0.05)      # Using a flat 5% interest rate

lc = LifeContingency(life, yield)  # LifeContingency joins the risk with interest


ins = Insurance(lc)                # Whole Life insurance

Any reason to not extend survival() to work on life? Currently only has method for ins. Similar for other functions, e.g. survival(life,30,35)